On Wed, Jul 15, 2009 at 1:55 PM, Rickard Öberg<[email protected]> wrote:
> 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();
Well, in reality you are talking;
migration.migrate("org.hedhman.niclas.Abc", Def.class.getName())
.isSame();
since the original class is unlikely to still be around, right?
> 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.
Good points. There are also questions around indexing; Since I assume
that the indexing should keep the old types around, one could possibly
leverage indexing for marking the entities migrated with a link or
attribute, in which case a query would answer the question whether any
migration would be needed. If index should be purged of old types,
then such strategy won't work.
Regarding 'backup' database; Well, I would recommend against that as a
general feature. Instead, migrate one object/aggregate at a time, and
just leave the old ones as they are completed. If rollback is wanted,
one can either delete all the migrated objects, or do a entitystore
specific copy of the files, bla bla... We don't have an issue in
general of multiple schemas interference, so things should be fine.
Possibly anice feature could be to allow a migrated object to be
marked read/only, so any old client would be able to read old data,
but not update it.
> 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.
Yes, and this would need to be done anyway for "mapping" such as Neo
and QRM entitystores.
> 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!!
I can take a shot at it, starting shortly... Not that I consider
myself an expert of the field either.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
