David Leangen wrote:
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. :-)
That's what I think too, which is why I keep coming back to it. I've
looked through some of the JavaZone videos, and data migration is
mentioned in some presentations as a big issue. I know Agile folks
usually see the database as a that thing screws up agility and iterative
development as it is "slower"(/more inertia) than most other tools.
It seems to me that with a simple version number included in the stored
state this could be addressed. Kind of like how HTML pages say what
schema they follow using a version number. Now, I know we tried to
generate that version nr before, and it just didn't work, but with a
global application version it might be more feasible.
So I go ahead? Step 1 is ONLY introducing a version() method in
Application, and then a Migration service specific for JDBM-EntityStore.
Once that seems to work that can then be refactored to SPI.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
