When using the phrase *some* I was referring to the possibility of
lazy migration.
In revision 1.0.1 we lazily add a property X to entity Foo. Since the
emigration is lazy, instances are only upgraded as they are touched.
So the system may contain some instances of Foo that are migrated to
1.0.1 and some that are not.
Now we deploy release 1.1 (with property Y added to Foo).
This means, that we should migrate 1.0 (add X and Y) and 1.0.1 (add Y)
instances differently.
I believe the easiest way to express that is with
migration
.fromVersion
("1.0
").toVersion("1.0.1").onEntity("Foo").addProperty("X","defaultvalue");
migration
.fromVersion
("1.0.1
").toVersion("1.1").onEntity("Foo").addProperty("Y","defaultvalue");
If we only register toVersion, the system will have to guess correctly
that version 1.0.1 is the next one after 1.0, so that migration-
to-1.0.1 and migration-to-1.1 should be performed when touching an 1.0
instance.
With the potentian to guess wrong.
Another question is how to handle the case where a release contains no
changes to an entity.
In the system above we might have an entity Bar, which has no change
in 1.0.1 and gets a new property Z in version 1.1
How should that be handled when 1.0.1 is deployed? When 1.1 is deployed?
One possibility is to perform an "empty" migration from 1.0 to 1.0.1,
doing nothing but bumping the applicationversion number. The easy
solution, but with redundant work, both for the developer and the
entitystore.
That might be expressed as
migration
.fromVersion
("1.0
").toVersion("1.0.1").onEntity("Foo").addProperty("X","defaultvalue");
migration
.fromVersion
("1.0.1
").toVersion("1.1").onEntity("Foo").addProperty("Y","defaultvalue");
migration
.fromVersion
("1.0.1
").toVersion("1.1").onEntity("Bar").addProperty("Z","defaultvalue");
Another possibility is to accept that not all instances have the
correct application version. Since there is no migration on Bar from
1.0 to 1.0.1, the client may (when 1.0.1 is deployed) receive a mix of
1.0 and 1.0.1 instances of Bar. This should be no problem, since they
have the same set of properties.
When 1.1 is deployed, we may have instances of 1.0 and 1.0.1. A way to
express these migrations might be as
migration
.onEntity
("Foo
").fromVersion
("1.0").toVersion("1.0.1").addProperty("X","defaultvalue");
migration
.onEntity
("Foo
".fromVersion
("1.0.1").toVersion("1.1")).addProperty("Y","defaultvalue");
migration
.onEntity
("Bar
").fromVersionRange
("1.0","1.0.1").toVersion("1.1").addProperty("Z","defaultvalue");
(fromVersionRange could use simple string comparison to match the
numbers).
Am I making sense?
/Kent
Den 19/09/2009 kl. 05.24 skrev Rickard Öberg:
Kent Sølvsten wrote:
When 1.0.1 is deployed, *some* of the entities will be migrated to
1.0.1
When 1.1 is deployed, the persistent state will contain some
rev-1.0 and some rev-1.0.1 entities.
Correction: all entities will be migrated to 1.0.1, it's just that
most entities will not change at all during that migration. The
stored version of all entities must be "1.0.1" though.
We can just express the migration rules as:
* add property X to all 1.0 instances (thus upgrading them to 1.0.1)
* add property Y to all 1.0.1 instances (thus upgrading them to 1.1)
When we fetch an 1.0 entity, both migrations should be performed
before returning the entity to the client.
So in the normal case it is sufficient to base the migration on the
existing version (and remember to update the applicationversion on
the entity).
Hm.. I'm not sure what you mean by "base the migration on the
EXISTING version". The rules have to be *expressed* with the version
being migrated TO, not from.
Let's say you have 1.0, 1.0.1, 1.0.2, 1.0.3, and 1.1. In 1.0-1.0.3
there are no changes at all. Then 1.1 adds a property. This should
be expressed as:
migration
.toVersion
("1.1").onEntity("someentitytype").addProperty("X","defaultvalue");
If the migrator sees an Entity with version 1.0, 1.0.1, 1.0.2 or
1.0.3, given the above rule it can make the change (add the
property) and bump the version to 1.1.
/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
