Hey,
I have fleshed out the Migration API now. All basic operations should be
in place (add/remove/rename properties/associations/manyassociations +
change entity type name). The actual operation code has been extracted
into a service that is passed into migration operations, which makes it
easier to ensure that custom operations behave the same way as the basic
ones. Also, if the migration operation succeeds it will cause an event
that can be listened to. Right now there is a simple logger that will
log all migration events to the JDK Log API.
Here's an example of how you could implement a custom migration
operation. Let's say you have a property "bar" already, and want to
create a new property which is "Hello"+<value of bar>. The custom part
is how to generate the new value. The actual operation that it performs
are all basic operations, in this case "addProperty". Here's the code
for this, from the MigrationTest in Git:
toVersion( "2.0" ).
renameEntity(TestEntity1_1.class.getName(),
TestEntity2_0.class.getName()).
forEntities( TestEntity2_0.class.getName() ).
addProperty("bar", "Some value").
removeProperty( "newFoo", "Some value" ).
custom( new CustomBarOperation() );
---
The last line declares the operation to be performed when migrating from
v1.1 to 2.0. The implementation is:
private static class CustomBarOperation implements MigrationOperation
{
public boolean upgrade( JSONObject state, StateStore stateStore,
Migrator migrator ) throws JSONException
{
JSONObject properties = (JSONObject) state.get(
MapEntityStore.JSONKeys.properties.name() );
return migrator.addProperty( state, "customBar", "Hello "+
properties.getString("bar" ));
}
public boolean downgrade( JSONObject state, StateStore stateStore,
Migrator migrator ) throws JSONException
{
return migrator.removeProperty( state, "customBar" );
}
}
---
I.e. get the "bar" property value, prefix with "Hello " and add as a
property. These custom operations can be arbitrarily complex, and they
can use information not only from the migrated entity, but also from
other entities by using the StateStore interface through which they can
access other Entities.
I hope this API will allow not only all the simple migrations, but
really arbitrarily complex changes. If anyone has a case that cannot be
handled, please let me know and we'll see if we can fix it.
Lastly, email really is too expressionless to convey the enormous
excitement I have over the migration API finally coming into place. It
has been an important vision of Qi4j from the beginning to make
migration easier, and I know that it is one of the biggest stumbling
blocks of both Agile and DDD practices today, as inert persistence
mechanisms really can get in the way of iteratively changing the domain
model as new insights come along. This is a big moment IMO :-)
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
