2009/2/19 Rickard Öberg <[email protected]> > Hey, > > One thing we have talked about from the beginning is the ability to > magically migrate objects from one schema to another on a per-object > basis. This allows giant databases to be lazily migrated, thus > minimizing downtime. It might also make it easier to restore backups > with old data in old versions into a new system. > > The basic need for this to work, AFAICT, is that EntityType needs to > have a schema version. I have now implemented an algorithm that for each > EntityType creates a hash for it, which includes the name, all > properties and all associations. Properties may point to values, which > in turn may have values, so they are calculated recursively. In the end > you get a SHA hash for all of it which is then BASE64-encoded. Here's an > example: > Bn6JdWca04SD4xF7Ckut0JvCxQI= > > If you change the name, any property, or any value of a property, and so > on, the hash will change, and so this can be detected simply by > comparing these strings. > > This means that if for each object we store not only the state and type, > but also this version string, it should be possible for us to later > detect that the state is out of date, and then perform migration of it > by applying rules to transform it to a new version. This migration might > be done as the entity is loaded, or through batchprocessing of an entire > database. Both would have pro's and con's. > > If you wanna take a look at this, you can run > EntityTypeSerializerTest.testEntityTypeSerializer() and look at the > generated version. Try changing the TestEntity or any of its values and > see what happens! > > One question is where to hook in migration services. This should > probably not be done in the EntityStore, but rather be something that > the UoW layer does. But how? Any ideas are welcome. > > I'm really excited by this! Being able to easily perform schema > migrations as the system evolves is one of the truly enabling features > of an "Agile framework", I think, and this is an important milestone > towards that. >
interesting, sounds very similar to a distributed SCM like git, especially wrt. managing changesets and using SHA hashes can there ever be a generic migration service - one that does the safest possible population, but would leave bits unfilled? or should every schema change also provide an associated migration snippet (or mapping) that can handle that change? also if a piece of data is several revisions out of date then would the migrations need to be composed in sequence? lots of scope for prototyping new ideas :) /Rickard > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Cheers, Stuart
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
