Geert Bevin <gbevin <at> uwyn.com> writes: > > Hi John, > > > So here are my thoughts on data migration. > > - What you want to be able to do is "patch" a database with all > > the changes > > since some point in time, or "roll-back" to some point in time. > > - I like the idea of MigrationOperation classes. I think these > > need to be > > identifiable by some ordinal, sortable data--by naming convention, > > static > > field, etc. E.g. newsItem-2006-05-20 or newsItem-1.03.RC1-a. > > Well, instead of relying on naming conventions, this would simply be > handled by the order in the list that is returned from migrateForward/ > migrateBackward. People will most probably adopt such a naming > convention though. >
I guess I don't understand what you are proposing. How does the list of MigrationOperations get populated, by whom? The naming convention, combined with the meta-data table (maybe TABLE_VERSIONS), allows the system to determine which ones to apply, and in what order. > > - Then, at runtime, the install method could look for any > > MigrationOperations > > greater than the last_update_id. Or, given some property for the > > *desired* > > version, calculate the difference and apply all the migrateForward- > > s or > > Calculating differences is extremely complex, certainly when > relationships, custom database features, indexes, triggers, ... come > into play. Also not all databases support jdbc meta data > introspection in full. Which makes it virtually impossible to obtain > the required information from the current structure of the database. I wasn't thinking about figuring out schema differences automatically. When I talk about "diffs," I meant figuring out what migrations are necessary to get from the current version to the desired one. Also, in my mind, the install method is the trigger for all this. If a TABLE_VERSIONS record does not exist for a table, the current creation functionality kicks in. 2nd case is that the system detects DataMigrations that have a higher order (by convention) than the version in the table, and runs those in order--an auto-upgrade. 3rd case is that some environment property identifies a desired version, in which case all the DataMigrations between the desired version and that from the table are run. > > migrateBackward-s in order. Install would still create the table > > from scratch > > if no meta data for it exists. > > I think we should just focus on playing migration sequences. > > Here's another thought: we could also add support for calculating the > differences between two domain models. Ie. you keep the old versions > of your domain model in a class or package (just copying them to a > dedicated package might be easy). RIFE would then compare those with > the current model and figure out the migration operations on the fly > to go from one to the other. This is still complex, but doable. > Sounds possible, and very cool, but probably not necessary initially. > > - Along with all this, it would be cool to provide a utility that > > does all > > the diffs for all tables in the meta data. > > What do you mean by that? > java -cp <blah> DoDataMigrations <desired-version> [table,[table..]] - where no tables specifies means all that have a MetaData class. This is fun. Is this the right list for this kind of discussion? Thanks again. - John _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
