We used migrations on a recent project, but it was only a partial solution. Each programmer was responsible for writing their own migration, and then committing it to Subversion, and then they were suppose to warn the other programmers to update the database on their local machines. For some reason, the migrations would sometimes work for some programmers and not for others.
The worst thing about the migrations is they quit whenever they run into an error, and it is not obvious where they quit. For instance, suppose you are at version 23 of the database (the version number is suppose to be maintained by the plugin code). You then try to upgrade to the newest migration. The newest version is 28 (if you take the weekend off, while another programmer is busy, you might easily come back on Monday and find that your version of the database is several versions out of date). The code gets half way through version 25 and dies with an error. Possibly you might open the migration file for version 25 and hand edit it, but you can not run that file again, because the first half of that file describes changes which have already been made, and which therefore can not be run again. The only clean way to upgrade, avoiding all errors, is to DROP TABLE before making changes to a table, but clearly that is impossible to do on a live website - you could not afford to lose so much data. Most of the time the down() methods failed to work. Most of the time I'd get foreign key conflicts when trying to go back down(). (The main reason to go down was so that I could go up again.) What I found is that most of the time I had to do changes to the database by hand. On Sep 14, 10:21 am, ColinFine <[email protected]> wrote: > On Sep 13, 8:34 pm, Fotis Paraskevopoulos <[email protected]> wrote: > > > > > > > Hello All, > > > I would like to ask the group the different deployment scenarios that > > have been setup. I am specifically looking for some information on how > > you manage your database deployment when some changes need to be made. > > > For example I deploy version 1.0 of the site/application and I need to > > make some small fixes which require database changes on the server > > side. > > > From what I have seen most people use svn or rsync to handle remote > > deployment of the symfony files. This is simple to automate or to > > create a one click action to deploy a new version. > > > So basically I am asking how do you effectively handle database > > changes. > > There is a plugin called something like sfMigrationPlugin (haven't got > access to my symfony projects here) > > You need to write the specific SQL that is needed to migrate from one > version of the database to the next and back again, but once you have > done so, it keeps track of which version your database is currently > at, and will apply the SQL to update it when you tell it to do so. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
