And, a little fairy in my ear tells me Doctrine will be the default ORM in symfony some time in the future.
- Jon On 10/23/07, Jonathan Wage <[EMAIL PROTECTED]> wrote: > > 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.0and > 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 -- 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 -~----------~----~----~----~------~----~------~--~---
