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? -- Paul Hoadley http://logicsquad.net/
_______________________________________________ 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]
