Re: Migrations in parallel code branches
Re: Migrations in parallel code branches
- Subject: Re: Migrations in parallel code branches
- From: Maik Musall <email@hidden>
- Date: Tue, 09 Oct 2012 12:39:05 +0200
Am 09.10.2012 um 12:32 schrieb Paul Hoadley <email@hidden>:
> Hi Maik,
>
> On 09/10/2012, at 5:41 PM, Maik Musall wrote:
>
>> 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.
>
> I've run into this as well, both using Wonder migrations, and on a project where manual migrations were performed using sequentially numbered scripts. We tried workarounds like "reserving" particular slots, but that's a partial fix at best, because, as you say, you've still got to manually pay attention to what's been applied where. Moreover, although I don't think I've run into it myself, I don't think it would be too hard to contrive a sequence of migrations that either relied on being executed in a particular order, or left the database in a different state depending on the order in which they were executed.
>
>> 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.
>
> It certainly sounds interesting to me. Would you envisage providing it as an alternative to the current system, or a replacement? Any thoughts on solving the kind of edge cases where migrations are dependent, or not tackling that?
I don't know if it can be made in a directly compatible way, but I would at least aim to make the transition painless for existing projects. I'd probably extend the current implementation. Dependencies like order of execution would need to be supported, of course. IMHO expressing dependencies like "migration A depends on migration B to be executed before A" would be better than a plain sequence numbering anyway.
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