We are using integer migrations - I had the same thought regarding the lock 
on the schema_info table. I will see if I can get something working.

On Friday, 20 February 2015 12:03:52 UTC+11, Jeremy Evans wrote:
>
> On Thursday, February 19, 2015 at 3:12:54 PM UTC-8, Bethany Skurrie wrote:
>>
>> I have an application that currently runs its migrations on startup. We 
>> are investigating whether or not we could run this with multiple AWS 
>> instances sharing the same database. Our concern is that both instances 
>> will try to run the migrations at the same time, as there does not appear 
>> to be any locking to prevent this. Has anyone faced/solved this issue 
>> before? I believe it would be reasonably straightforward to add a locking 
>> mechanism using normal database table locking, but I'm sure someone else 
>> must have tired this before, and I would like to hear from them!
>>
>
> My personal preference is to not migrate on startup, but migrate manually 
> via a rake task.  For any applications with stringent uptime requirements, 
> you basically must write your migrations in such a way that your old 
> application code will work continue to work post migration.  Apps without 
> stringent uptime requirements can always just stop the app, run the 
> migration, and then start it back up, so migrating on startup works for 
> those, at least in the single process case.
>
> I'm open to supporting locking on migrations, at least as an optional 
> feature.  For integer migrations, a FOR UPDATE lock on the schema_info 
> entry may be sufficient.  However, for timestamp migrations it would be 
> more complex.  If anyone wants to take a stab at implementing this, please 
> let me know.
>
> Thanks,
> Jeremy
>

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Reply via email to