Hi Thierry: In the Symfony spanish list, someone recomends liquibase ( www.liquibase.org) . This is a Eclipse plugin.
Regards. 2007/11/9, drmikecrowe <[EMAIL PROTECTED]>: > > > 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 > > > > > -- Boris Duin Celular: 0416-8136373 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
