There hasn't been much talk about the database migrations here. Are most people using the doctrine migrations functionality? I do really like this tool for my small projects, but on larger applications with databases from 10 - 100 GB of data, I'm much happier with the performance of a direct DB change script.
When it's a mysql project I use SQLYog structure comparison to create a DB migration script to sync stage (then production) with the development db. I collect data change scripts from my developers (and test these in the staging environment test) The advantage to this is that the DB migration runs very quick as there is no web server overhead. The downside is that I don't have all of the functionality of up/down scripts :( . Also, it's take a decent level of change control to ensure that I have received data change scripts from all of the projects developers. It would be really awesome if there was tool to generate a raw sql file from a doctrine migration task. On 2nd thought.... I could just run the migration scripts (in my test/stage environment) and record all the queries, thus building a script for the production migration! On Jul 10, 8:44 am, Eno <symb...@gmail.com> wrote: > On Thu, 9 Jul 2009, Jonathan Wage wrote: > > They are just ruby scripts :) > > I know. > > > do this has existed for a long time, outside of symfony. I would recommend > > using some existing best practice for deployment like the svn diff/patch and > > capistrano approach. > > I just wish there was something like Capistrano but in PHP :-) > > -- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
