Not sure how you will end up solving this, and I don't have anything
useful to say right now, but I just thought I'd mention that at least
for me (and a few others I've talked to), just the versioning support
alone would provide enough value to warrant basing development on Qi4j!
This is a huge deal. :-)
Cheers,
=David
On Sep 17, 2009, at 1:13 PM, Rickard Öberg wrote:
Hey,
Yes, versioning again. I have thought some more about versioning and
am coming back to that while the previous scheme was way too
complicated, and that it's an implementation detail, Qi4j could
still help somewhat to make it easier.
To do data migration in key-value stores it would be useful if each
stored entity had a version number of the entire application, rather
than the version of the entity-type that we played with in the SPI
some time ago. This way it becomes easier to specify migration rules
and ensure that data is in a consistent format. Importing old
backups would also be possible, as it could be upgraded on the fly.
Here's what I suggest: in Application we add a method version(),
with a corresponding method in ApplicationAssembly to set it. What
to set it to is up to the user. It could be on the "1.2.3" format,
or it could be revision nr (e.g. "345"). Just something that makes
sense for the application. Then, the default EntityStore
implementations would store this version in the data. When state is
read the stored version can be compared with the current version. If
they are the same, all is ok. If they are not the same, then a
Migrator service should be invoked.
The Migrator service, and how to configure it, is not defined. Well,
the Migrator interface would be defined in the SPI, but there could
be many implementations, with different strategies. One would be to
declare rules using some Fluent API, like so:
migrator.
onVersion("1.2.1").
forEntities("SomeEntity").
renameProperty("oldName","newName").
addProperty("name","someDefaultValue").
removeAssociation("someName").
migrate(new CustomEntityMigrator());
and so on. This should allow pretty powerful possibilities for doing
both standard and custom migrations. The migration could either be
done lazily on read, or eagerly on startup. This could be specified
as well in such a fluent API:
migrator.onVersion("1.3.0").eagerMigrate();
All of this would be done in the assembly phase, btw.
Another implementation could take a JSON-export of the database and
serialize it to XML and use XSLT for the rules. And yet another one
could post it to some REST-resource that performs the
transformation. And so on.
But the point is that if we just add the version property in the
Application API, and a Migrator service that EntityStores can call,
then I think that would be enough.
I have quite urgent need for it, so unless this is an obviously bad
idea I would like to go ahead and add it.
What do you think?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
