I have thought about this when I initially wrote the migrations code in Doctrine and I think the way I was going to implement it was to make changes to your models/schema then we use Doctrine to generate the models/schema from the current existing database. Then we will write some code which will compare 2 sets of models/schema files and generate migrations for the changes between the 2..
This way you will be able to make your changes in the database and then compare your existing models/schema files to the existing database structure to produce a migration path, or make your changes in the schema/models then compare the current database to the new schema/models. The ideal way to do it I think would be to update your schema/models, compare it to the exisitng database to product a migration, then run migrate task and your database will be upgraded for the changes you made to your schema. If you make your changes in the database and generate migrations that way, you will have to update your database version table, and still make the changes in your schema files. - Jon On 11/22/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > > > > On 22.11.2007, at 21:46, Wicked wrote: > > > > >> I can just make a backup copy under a new name when I run the tool to > >> create a diff. That way I have the copy available for the next run of > >> the script. > > > > Ok, I see your standpoint. And it doesn't look like a correct way for > > me. > > What I'm thinking is that using migrations should satisfy following > > requirements: > > 1) each VCS (svn, csv, whatever...) revision should be atomic. So each > > migrations between any two revisions should describe the same changes > > that were done in the schema. So, e.g. changing schema in one > > revision, but migration in a following one should be restricted. This > > is mostly about development culture. > > i prefer small teams and there i prefer a commit often approach for > things that people work on together to keep people in the loop. when > people work on something on their own, then its not so ueber critical > that there is a migration anyways, so in that case i am also not so > concerned. > > that being said i have never done a true TDD project and i see that > not having a migration around for every commit would mean that the > tests start exploding which would suck. > > > 3) it should be handy and maximally automatic. What you're saying > > about - to make backup files - seems messy to me. Unfortunately I must > > admit I would use `schema-diff schema.yml .svn/text-base/ > > schema.yml.svn-base` instead of your way. As I would say, it's the > > least of evils :) Probably some script would do backing up, but again, > > it should follow the requirement #1, so as I see something like svn > > keyword $id: $ will be a must some way. > well if it makes you happier you could use svn:externals to point to > the earlier revision of the file (not sure if that is actually legit > in svn). > > regards, > Lukas > > > > -- Jonathan Wage http://www.jwage.com http://www.centresource.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
