"kerinin" <[EMAIL PROTECTED]> writes: > 4) run a migrate script (eg 'tg-admin migrate'). This script would > drop the site's database and reinitialize it (sql drop && sql create).
Why dropping? It would be more efficient to issue several ALTER TABLE, etc. than dropping information. If you have user passwords, important data, etc. you can't drop it. > The new database would conform to the updated site's model definitions. It would as well if you changed it with ALTER statements. > The migrate script would then populate the new (empty) database using > the backup copy and the migration file created in step 1 How? What would it do about new mandatory columns? Or columns that doesn't exist anymore? Or if data was moved from one table to another (e.g. when you had a 1:1 relationship and now you have a N:M relationship)? > 5) "tg-admin migrate" would delete the old site copy and drop the > transfer database if the migration completed without errors Why not keeping it there? Dropping a database manually is a one command only thing. And safety is never enough... > The migrate script would move data between the old and new sites by > essentially starting both simultaneously. It would scan the new site's > model for all the defined classes and populate them based on the > migration file. What about columns that changed places? Or if I had a StringCol/UnicodeStringCol and now I have a ForeignKey or MultipleJoin in place? What about required columns? > Migration files would specify differences between the two models. > Unless you specify otherwise in the migrate file, "tg-admin migrate" > would assume that any class or property with the same name in both the > new and old model has not changed, and assign the value from the old > version to the new version. > > Anything that has been changed could be specified in the migrate file, > so for example if Class.property1 had been renamed to Class.property2, > you could specify something like this in the migrate file: > > new.Class.property2 = old.Class.property1 Could it be new.Class1.property_text1 = old.Class5.property_text3 ? > Ideally, "tg-admin migrate" would provide a set of conversion functions > allowing you to do thing such as change MultipleJoins to RelatedJoins, > or FloatCol's to IntCols - something like this: > > new.Class.property1 = MultipleJoinToRelatedJoin( old.Class.property1 ) > new.Class.property2 = FloatColToIntCol( old.Class.property2, > round='down' ) > > You could also specify ways in which the old database would need to be > changed to conform to the new model: > > new.Class.version = old.Class.version + 1 > > To clarify a bit: if you had the following classes: > > OLD--------- > def Journal_Entry(SQLObject): > date = DateTimeCol() > content = StringCol() > > def Link(SQLObject): > uri = StringCol() > > NEW--------- > def Journal_Entry(SQLObject): > date_created = DateTimeCol() > content = UnicodeCol() > > def FavoriteLink(SQLObject): > uri = StringCol() > comment = StringCol() > > MIGRATE----- > new.Journal_Entry.date_created = old.Journal_Entry.date > new.Journal_Entry.content = StringColToUnicodeCol( > old.Journal_Entry.content ) > new.FavoriteLink = old.Link > > -------------- All your examples are for changes inside one table only. What if I'm migrating data from one table to another? > the migrate script would retrieve all the new model's classes, discover > the Journal_Entry class, and retrieve all instances of that class from > the old site's backup copy. For each existing instance, it would > create an instance in the new site. Each new instance's property > 'date_created' would be set to the old instance's 'date' property. > Content properties would be converted to unicode. etc. > > The benefits of doing migrations like this is that the migration would > be completely independent of the DB Provider (in fact it would be a > good way to change between SQLAlchemy and SQLObject), involves no > tinkering with SQL, and plays well with version management software. I use SQL script files with my management software. :-) > Comments? Dropping the database is bad. We'd loose views, functions, stored procedures, extra indices, rules, etc. from it because those things can't be described with the ORM and are *HUGE* performance improvers, besides providing nice abstractions. Why would one need to take the site down? It would be more useful to make a copy of the running database, perform all commands needed to convert it from one state to the other (one might want to go back...) and then prevente data insertion and updating on the old database while inserting records onto the new one. This would minimize downtime (all records would be queriable, but they won't be modifiable) and would preserve all structures one has created in parallel to the ORM. Also you should remember to use the exactly same "id" column value. Changes might lead to problems -- both in code (bad practices...) and legally. -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
