Rails migrations with no downtime

Post by jaylevitt » Mon, Feb 13, 2012, 11:34 PM UTC

JonnieCache wrote: post #17

morganpyne wrote: post #15

Earlier quoted context omitted.

Interesting. As you have probably guessed by now, I'm not a Rails developer and therefore did not know this. I was surprised to read about this after your comment and find that Active Record went the lowest common denominator route with this and therefore gave up any native foreign key integrity support.

There is nothing to stop you using foreign key constraints with rails, the activerecord migration api includes methods to create them for the major db adapters and there are plugins to automate the process to some extent. It's not the Rails Way™ because it sacrifices some database-agnosticity, and therefore almost noone does it. People achieve the same behaviour with application-level validations in the model. I'd wa…

The gem 'foreigner' makes them painless, and supports Postgres, Oracle, and I think MSSQL.

Post by kfool » Tue, Feb 14, 2012, 2:51 AM UTC

morganpyne wrote: post #10

There is another problem unmentioned in this article with his simple table modification example... When you modify a table the DB needs to write the entire table to disk, locking it all the time. Depending on how much data is in the table and how fast your IO is this can be hours and hours of downtime on the live database, for a migration that only took a few seconds locally on your test database. Running migrations…

The issue is not performance. The issue is backward compatibility.

ALTER TABLE performance will eventually improve. PostgreSQL 9.1 lifts-off the lock-up limitation.

But what a performant ALTER TABLE will not improve is its intrusiveness to applications. When you change the schema you break the app.

That's the problem.

http://chronicdb.com/blogs/change_is_not_the_enemy

Re: Rails migrations with no downtime

Re: Rails migrations with no downtime