(adding Qi4j-dev in CC)
Niclas Hedhman wrote:
Well, you didn't answer the
Jan - Release 1.0
March - Release 1.1
April - VIP customer of 1.0 wants bug 123 fixed (but don't want
upgrade). Released as 1.0.1
June - 1.2 is released with bug123 fixed as well.
which I know is a common thing, especially in enterprise scenarios
with big fat support contracts.
And we are here assuming that bug123 is not only a bugfix but also
changes the persisted state then?
With the API I mentioned in a previous post this should be ok I think:
migration.toVersion("1.1")
.<1.1 changes>
.toVersion("1.2").<other fixes plus 123 fix>
migration.toVersion("1.0.1")
.<123 fix>
.toVersion("1.2").<other fixes minus 123 plus 1.1 changes>
If you want to upgrade to 1.2, for each entity stored:
On: 1.0
-> apply rules for 1.1 and then 1.2
On: 1.0.1
-> apply rules for 1.2 in the 1.0.1 branch
On: 1.1
-> apply rules for 1.2 in the 1.1 branch
So it will be a matter of finding the best matching rules given current
version and the version you want to upgrade to.
Actually, I want to see how this is going to look like. Because on one
hand I get the impression that this fluent API ends up as an
implementation detail in a Migrator service, otoh it sounds like a
"this is how it will be set in stone"-API as well. If the fluent API
ends up in qi4j-bootstrap, then it should be expressing "from-to"
statements, as that allows all that has been discussed (linear,
branched, named) version systems.
Agreed, but hopefully the "from"-"to" can be expressed as I have shown
in the API without having to explicitly say "from", as that can be
implicitly extraced from the usage of the API.
Makes sense?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
