IMHO, I think you are over complicating for no obvious gain. If two features are developed in parallel, either reconcile them before release / production or, if they are released separated, just rename the latter migration before release. You are using development databases for each developer, and periodically reseting them, right?
I have the exact situation that i'm developing two different features on two different branches of code. The migrations on each branch are named the same because I do not know which one I'll release first. Then I'll rename the other. The only pain, that last 5 seconds, is reseting the database when I change branch. That's a simple "gzip -dc db.dump.gz | psql dbname" Schema changes are always a bottleneck and a natural serialization path for parallel developments. Just the way I see it. anybody is welcome to prove me wrong ;-) Henrique Gomes On Oct 9, 2012, at 10:53 AM, Maik Musall wrote: > Hi, > > of course there would need to be some possibility to specify such a > dependency. > > Maik > > > Am 09.10.2012 um 11:45 schrieb Johann Werner <[email protected]>: > >> You would still have the problem of the order in which the migrations have >> to be run in. Often the migrations are independent of each other but >> sometimes they aren't. >> >> jw >> >> >> Am 09.10.2012 um 09:11 schrieb Maik Musall <[email protected]>: >> >>> Hi, >>> >>> is there a best practice that I'm not aware of if features are developed in >>> two separate branches which both contain migrations, like by two >>> developers? Those migrations typically end up having the same sequence >>> number p, so they can't easily be merged. Even worse, if you rename one to >>> have a higher number q and then merge them, you have to manually pay >>> attention to which migration has already been executed on which database as >>> number p. If you don't, either could end up not being executed, and/or >>> startup fails because the migration is attempted to be executed twice. >>> >>> Wouldn't it be better, instead of just a single number, to have one entry >>> per migration in the _dbupdater table so that >>> * migration classes could be named freely >>> * merges would be painless >>> * all databases would update automagically again? >>> >>> I'd like some feedback on that idea. If everybody finds it a good proposal, >>> I'd start implementing that. >>> >>> Maik >> >> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/lists%40farol.pt > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
