[LRUG] Destructive Migrations - best practices

Ian Kynnersley iankynnersley at gmail.com
Fri Mar 16 03:52:35 PDT 2012


Hi,

In one of my current projects, the implementation of one of the models is
changing a reasonable amount. There will be a batch of new fields and a
couple that are no longer required.

What is the best practice for writing migrations that remove columns from
tables? I'm thinking specifically of providing the ability to rollback the
changes. Should I ignore this and just write an "up" migration to delete
the columns? Should I create a duplicate table at the point of the
migration to keep a history of the data in those columns? Should I leave
them in the database to fester while removing references to them from the
code?

The API docs say:
"Some transformations are destructive in a manner that cannot be reversed.
Migrations of that kind should raise an ActiveRecord::IrreversibleMigration
exception in their down method."

This seems to go along with my first option but seems unsatisfactory for a
production app.

This covers some nice options (like backing up to a file):
http://stackoverflow.com/a/621363/264376 but I'm interested in what people
on here think.


Cheers
Ian


-- 

Ian Kynnersley
http://iankynnersley.co.uk | +44 (0) 7973 420 829 |
http://twitter.com/kpopper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120316/ee74493d/attachment.html>


More information about the Chat mailing list