On 13 Jan 2015, at 10:16 am, OC <o...@ocs.cz> wrote: > But after first going through I am none the smarter and it does not seem to > me it would help. Perhaps I am completely missing the point, but seems to me > this is intended to a completely different task than the one of mine?
It might be just solving the same problem differently. What you've described as your workflow seems fairly dynamic (reading the database, adding properties at runtime, adding and removing columns, and so on), and migrations as implemented in er.extensions.migration are not at all dynamic: you manually keep the database in sync with changes to the model using Java code that is run (if required) at application startup. > Might be wrong, so far, I do not quite get what the migration stuff does, not > speaking of the slightest idea how could I exploit it. I do not have versions > (unless you simply define „any change in DB makes a new version“, in which > case of course I have them, but this does not seem to help), A "version" for the purposes of migrations means any change to the model between re-deployments. (How it works in real life is somewhat dependent on your development/deployment methodology. You could certainly make a bunch of changes to the model over time, but package them into a single migration class to run against the production database next time you deploy.) > and I neither "upgrade" nor "downgrade" anything. It's just arbitrary terminology—you "upgrade" the database to reflect changes to the model. Theoretically you could "downgrade" the database to revert to an earlier version of the model, though that functionality was never implemented anyway. > Well... this version of my app _does_ do that at startup only, but future > versions definitely should be able to re-read the data -- (a) -- and re-do > the synchronization of model -- (b) -- and database -- (c) -- essentially at > any time (of course, locking completely out all other instances when it is > being done). I really don't know if Wonder migrations are going to solve your particular use case, but it's certainly worth a look. If you need the two-way synchronisation you describe (that is, from database back to model as well), then migrations are not going to help you. It's strictly one way: model to database via Java. -- Paul Hoadley http://logicsquad.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
