• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Migrations and dev cycle
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Re: Migrations and dev cycle (From: Pascal Robert <email@hidden>)

  • Prev by Date: Re: ERAttachment problem feedback
  • Next by Date: ERXPartials review and Example application
  • Previous by thread: Re: Migrations and dev cycle
  • Next by thread: Re: Migrations and dev cycle
  • Index(es):
    • Date
    • Thread