Re: Migrations in parallel code branches
Re: Migrations in parallel code branches
- Subject: Re: Migrations in parallel code branches
- From: Henrique Gomes <email@hidden>
- Date: Tue, 09 Oct 2012 11:44:30 +0100
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@hidden>:
>
>> 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@hidden>:
>>
>>> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden