Schema Evolution In Oodbms

I know how this works in relational databases, but how do you change the layout of your object oriented database when you have critical data in the existing database?

In GemStone/S it was pretty easy. When you committed the new class definition to the database, all instances of the previous version of the class would automatically have their class pointers changed to point to the new version of the class definition (unless you specified that they shouldn't), and simple rules would be applied to establish the values of the instance variables in the instances of the new version of the class. If more complex transformations of instance variables were required between class versions, there was a facility to make the transformations.

In GemStone/J it is more complicated. If you want to "deploy" a new version of a class that has persistent instances, you have to follow a certain procedure and possibly provide some "transformation specification" classes that you code against a supplied API.

--RandyStafford

So the Oodbms is fundamentally part of the image you're executing? Isn't this rather a restriction? I can't have a shared Oodbms between two applications? Do all Oodbms work in this way?

Of course, I could make my program something that can serve data to other programs, but then I'd get impedance mismatches etc. all over again.