Geert Bevin <gbevin <at> uwyn.com> writes: > > MetaData classes could have migrateForward/migrateBackward methods > > which > > contain only the most recent deltas. And some constraint-like > > mechanism could > > Very interesting approach, I hadn't though of using the MetaData > merging for this. I like it! Maybe it's possible to have all the > changes in there by returning a collection of MigrationOperation > classes from the migrateForward/migrateBackward methods. These can > then be inner classes and just stay present. > > > define the table changes. For this to be effective, you'd have to > > be using > > The main missing part is the lack of an AlterTable query builder, as > well as CreateIndex and DropIndex. The first step to schema > migrations is the presence of these. They should not be difficult to > implement at all, just some time is needed. The other query builders > are good examples of how to do it. > > > version control, and probably tagging for every schema change. > > Backing up > > would be painful, but mostly we'd be moving forward. There is also > > the issue > > of deciding when/how to run the migrations, the RAILs approach is > > manual. > > Maybe have a way of checking the meta data against the database, and > > attempting migrateForward is a difference is detected? > > I have already added something like that to RIFE/Crud. It records the > last modification time of a CRUD bean class file using the Java > preferences API. It just isn't used for any checking. The plan was to > use it for doing these automatic migrations. >
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. - Rife could keep some meta data on Rife-installed/maintained tables, maybe as simple as table_name and last_update_id (again, the sortable data). - 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 migrateBackward-s in order. Install would still create the table from scratch if no meta data for it exists. - Along with all this, it would be cool to provide a utility that does all the diffs for all tables in the meta data. Okey dokey, there are my ideas. FWIW and all that. I'm just sorry I can't take this on right now. Take it easy. - JT _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
