Doctrine has this functionality and is implemented through sfDoctrinePlugin. Here is a complete list of the available tasks currently available in sfDoctrinePlugin. The plugin is compatible with symfony 1.0 and 1.1 branch.
If you have tried sfDoctrinePlugin in the past, this is not the same sfDoctrinePlugin. It has been almost totally re-built and is near a stable release. doctrine-build-all > Create database, generate models, insert sql doctrine-build-all-load > Create database, generate models, insert sql, and load data from fixtures. doctrine-build-all-reload > Drops database, creates database, generate models, and load data from fixtures. doctrine-build-db > Create database doctrine-build-model > Build all Doctrine records doctrine-build-schema > Build yaml schema from an existing database doctrine-build-sql > Export sql for doctrine schemas to data/sql doctrine-convert-schema > Convert 0.1 schema to new Doctrine schema syntax doctrine-dql > Execute dql from the command line doctrine-drop-db > Drop database doctrine-dump-data > Dump data to yaml fixtures file doctrine-generate-crud > Creates Doctrine CRUD Module doctrine-generate-migration > Generate migration class template doctrine-generate-migrations-db > Generate migration classes from databases doctrine-generate-migrations-models > Generate migration classes from models doctrine-init-admin > Initialize a new doctrine admin module doctrine-insert-sql > Insert sql for doctrine schemas in to database doctrine-load-data > Load data from yaml fixtures file doctrine-migrate > Migrate database to current version or a specified version. doctrine-rebuild-db > Drop database and rebuild it On 10/23/07, Kay <[EMAIL PROTECTED]> wrote: > > > 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. > > > > > -- Jonathan Wage http://www.jwage.com http://www.centresource.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
