Hey,
I've started working on schema migration now, as I need it for a
project. Basically, on an application assembly you will be able to
declare all migration rules, and then these can be applied later. The
declaration is done using a simple DSL. Example:
MigrationAssembly migration =
module.layerAssembly().applicationAssembly().migrate();
// Entity class changed name
migration.migrate(TestEntity.class.getName(), TestEntity2.class.getName())
.isSame();
// Property renamed and added
migration.migrate(TestEntity2.class.getName(), TestEntity3.class.getName())
.renamedProperty("stringProperty", "stringProperty2")
.addedProperty("newProperty", "\"somevalue\"");
... and so on. There is also a .custom(Migrator) option where you can
supply your own migrator implementation, for cases which are non-trivial
and which requires coding.
The migration is done on a state-level, so there's never any actual live
instances during the process.
I anticipate that there will basically be two cases where migration is
done: either at startup time just after the application has been
activated, and lazily at runtime when the client tries to access an
entity whose stored type is old.
One question is: for the eager-case, how should it be decided that
migration needs to be done? To do it on every startup seems stupid. But
what indicates that there is migration work to be done? Also, should
migration be done to the application database, or to a copy, in case you
want to do a rollback. Or, would one have to do a copy of the database
before migration starts in order to achieve that.
Another question: for this to work properly the EntityTypes of stored
entities needs to be stored themselves in the EntityStore. Otherwise
there is no way to know what old types looked like. There is currently
no implementation of EntityTypeRegistry that does this, so that would
have to be fixed.
Finally, I am myself a relative newbie at data migration, and am also
really really short on time. If anyone wants to help out with building
this functionality, please do let me know!!
regards, Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
