I got into thinking about writing a Migrations helper... But there doesn't seem to be any code in propel to allow you to add/ remove columns from an existing database. It doesn't have any kind of helpers to let you modify an existing database schema at all.
So because of that, you wouldn't be able to do migrations in a database independent way. I think that doctrine is trying to have support for migrations though. I just don't want to rewrite my codebase to use it. On Oct 23, 12:44 am, me <[EMAIL PROTECTED]> wrote: > I searched and > found:http://trac.symfony-project.com/wiki/sfPropelMigrationsLightPlugin > as well as the other posts in this group regarding migration > integration for a future Symfony release. > > I would like to propose a more integrated approach that takes > advantage of the codebase from sfPropelMigrationsLightPlugin will > respecting the current schema.yml database configuration convention. > > I would suggest a process that might look like this: > > $> php Symfony propel-init-migration > > This would create the migration structure and set up the required > schema version tracking table in the database. > > A schema01.yml file would be created and this would increment with > each successive propel-init-migration command. > > The user would then enter their database schema and could then run a > process that might be something like: > > $> php Symfony propel-build-migration-all > > This could work like the existing propel-build-all command. > > I would suggest that fixtures remain as they are now and not be > integrated into this process. I find the iterative nature of MVC > development is well complimented by a migration type system. The only > weakness of the current sfPropelMigrationsLightPlugin is that it > requires the creation of raw sql which bypasses the typical database- > agnostic treatment that the ORM allows. > > This would be a useful Symfony core addition as it directly deals with > how developers manage their core schema that supports the models in > the application. While I agree that Migrations may not be fully > supported by everyone, they provide an extremely flexible way to > manage application development through the iterative processes that > many developers are currently changing to utilize in their work. > > I hope this suggestion isn't out of line. If there's a more formal > proposal process just let me know. I'm also keenly interested in > hearing the technical limitations or challenges of implementing such a > solution. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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-devs?hl=en -~----------~----~----~----~------~----~------~--~---
