[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Upgrading ozone applications
From: "Gerd Mueller" <gerd@smb-tec.com>
> > Has it been tried for more advanced refactoring schemes than just adding
> > and removing fields.
>
> No, none of the points below. And I guess it wouldn't work, since you may
get
> two objects where one is expected. What happens with references to object
> Cv1 ? Does they point after loading to Cv2 or B or what ? Those references
> have to be splitted too. At the moment I've got no idea how to handle
this.
A possibility:
You could store the class version ID with each object and run a lazy update
on instantiation in your creation callback event.
A simple example, using our callback syntax:
class fooStore{
int classVersion;
Object oldMember;
Object newMember;
void objectOnActivate(){
if(classVersion < 1){
newMember = oldMember;
oldMember = null;
classVersion = 1;
}
}
}
Your "objectOnActivate" would grow with the evolution of your objects. Any
complex update of the schema could take place. Typically you would place
more complex transformation code into your old class, so you could call it
from all classes that have a reference to this class.
In the design of our product we chose not to use serialization for the
storage of objects, for maintenance, performance and querying reasons.
Instead we use reflection. We store a superset of all class schemes ever
stored. In our upcoming 1.1. release, renaming a class or member is one
method call. Since there is only one reference to this name throughout the
system, all referencing classes understand the name change. You can even
change the datatype of a member with the same name back and forth. Of course
you would also need manual code to solve inconsistencies between objects
stored with two different versions of the class scheme.
Kind regards,
Carl
---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com