www.mysqldiff.org Fantastic too.
Or, I use these scripts: To save the database: mysqldump -u MYUSERNAME --password=MYPASSWORD MYDATABASE --skip-opt -- compact --create-options --complete-insert > sql/MYDATABASE.sql echo "SET FOREIGN_KEY_CHECKS = 0;" > sql/MYDATABASE.insert.sql grep INSERT sql/MYDATABASE.sql >> sql/MYDATABASE.insert.sql echo "SET FOREIGN_KEY_CHECKS = 1;" >> sql/MYDATABASE.insert.sql To rebuild with the new schema: rm config/generated*.xml ./symfony propel-13-build-all ./symfony propel-13-insert-sql To reload the data: mysql -u MYUSERNAME --password=MYPASSWORD MYDATABASE < sql/ MYDATABASE.insert.sql This handles adding fields very well. It does NOT handle renaming or removing fields. If you want to remove / rename fields, do that operation on the database before doing the first save. Otherwise, your sql file will be filled with inserts pointing to non-existent fields. Mike On Nov 9, 4:04 pm, Jonotron <[EMAIL PROTECTED]> wrote: > On Nov 9, 3:24 am, Thierry <[EMAIL PROTECTED]> wrote: > > > Is there any way to generate the sql needed to bring the structure of > > the existing database up to the specification in the schema.yml? > > > How do you guys handle db scheme changes? Any best practices? > > It's probably too for this now, but when I make changes to my schema, > I echo those changes in an SQL file that does the appropriate ALTERS > to my database. This does require dual entry though, I.E. you make > changes to the schema AND to a SQL update file. > > My method is to keep the SQL update files in /data/update path. I > name my files after the version that it brings the database to. E.g. > If my production application is at version 1.0.0 and I've got a bunch > of development changes and now I want to bring version 1.0.0 up to > date with my development version (which I have tagged say 1.0.1)... my > SQL update script is named /data/update/1.0.1-update.sql > > This way I can also ensure that I upgrade in the proper sequence, > incase I tag a few versions of my development copy, but for some > reason I don't put these into production for a few tags. E.g. My > development version is at 1.0.1 and since then I've developed a 1.0.2 > and a 1.0.3 and a 1.0.4 and now I want to upgrade my production from > 1.0.1 to 1.0.4... my /data/update/ directory contains 1.0.1- > update.sql, 1.0.2-update.sql, and 1.0.4-update.sql... so I run 1.0.2- > update.sql (not 1.0.1 since I am already at that version) then 1.0.4- > update.sql (there is no 1.0.3-update.sql perhaps because that version > had no model changes, just logic changes). > > Another benefit that I like of create update.sql scripts, is that > sometimes I might make a drastic change to the model (like combining > two tables, or splitting one table into two, for one reason or > another). This is hard to change the structure AND the data using > some kind of automated tool. It would require some SELECTs and > INSERTs and UPDATEs in addition to the ALTERs. So as long as I have > been cataloging my changes in my update scripts and thinking about it > as I make changes to my model, I am fine and it is rather quite easy > to perform production upgrades. > > J --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" 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/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
