> 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 <jonot...@gmail.com> wrote:
>> On Nov 9, 3:24 am, Thierry <thierryschellenb...@gmail.com> 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