Niclas Hedhman wrote:
On Mon, Sep 21, 2009 at 2:19 PM, Rickard Öberg <[email protected]> wrote:
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?
So, I think you have just set the limit to x.y.z notation, and strict
ruling on those versions. Build-number won't work, right?
It would work, but no fancy branch thingies if you choose that option I
suppose.
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>
So, the migrator would understand "somehow" that 1.1 would be skipped
in the latter of the two?
If you have a 1.0.1 entity and want to upgrade to 1.2, then only the
latter would apply, yes, I think so.
GutFeeling(tm) says these migration scripts
will become scary... Tool support?? But then, I can stick to custom
all the way if I want (probably with a pattern where the Migrator is
"near" the actual Entity, maybe an inner class or something).
Yup.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev