Re: Migrations and dev cycle
Re: Migrations and dev cycle
- Subject: Re: Migrations and dev cycle
- From: Theodore Petrosky <email@hidden>
- Date: Thu, 20 Sep 2012 17:59:05 -0700 (PDT)
--- On Thu, 9/20/12, Pascal Robert <email@hidden> wrote:
> From: Pascal Robert <email@hidden>
> Subject: Re: Migrations and dev cycle
> To: "David Holt" <email@hidden>
> Cc: "WebObjects Development" <email@hidden>
> Date: Thursday, September 20, 2012, 4:45 PM
>
> Le 2012-09-20 à 16:42, David Holt <email@hidden>
> a écrit :
>
> > Also, can you use dependencies to mitigate the risk of
> doing something incorrectly?
> >
> > Can you always do migrations in trunk regardless of
> where the necessity for them is being created?
>
> The problem is that if the migration is adding a non-null
> column, and the model don't have the attribute, the INSERT
> or UPDATE will fail. If you had it to the model, you need to
> add a value to that new column.
I had this problem. My solution was:
migration 3 update the database with allows null on the column
migration 4 (sometime in the future update the database records in the attribute that will require non-nulls.
migration 5 update the database to require non-nulls.
does this do what you are trying to do?
Ted
>
> >
> > On 2012-09-20, at 1:32 PM, Maik Musall wrote:
> >
> >>
> >> Am 20.09.2012 um 21:22 schrieb Pascal Robert <email@hidden>:
> >>
> >>> Hi guys,
> >>>
> >>> I was wondering how do you deal with situations
> where your development branch is having migrations that are
> NOT part of trunk/current release but that you need to do a
> migration for a fix in trunk?
> >>>
> >>> Let's say trunk is at migration 2 (on the prod
> database), but the "super new features" branch is at
> migration 5 (on the dev database), creating a migration 3 in
> trunk will create problems when trunk is merged with the
> "super new features" branch, and doing a migration 6 in
> trunk will make that migration 3-4-5 won't be executed in
> prod since prod will already be at version 6.
> >>
> >> My experiences with migrations are very limited so
> far, but how about making it a habit to do migrations as a
> separate commit, so you could cherry-pick migration 3
> separately into trunk?
> >>
> >> 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
_______________________________________________
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