[LRUG] Destructive Migrations - best practices

[mudge]

After being burnt by destructive schema changes at a previous job
(altering tables with tens of millions of rows), I would recommend not
making backwards-incompatible modifications as much as possible.

By this, I mean that it is always possible for you to rollback your
code and still be able to use your application without it blowing up
due to schema changes.

A recent example would be an application I was working on that stored
the location of a user interface component in terms of "x" and "y"
columns; the day came when we reworked the interface significantly to
add a third "zone" column.

My first approach was to laboriously convert all previous co-ordinates
into these new triples and write a similarly convoluted down migration
to convert them back (this took the form of a pair of rather
intimidating execute statements). In the end, I just added three whole
new columns and marked the old ones as deprecated in the code (issuing
warnings whenever they were used) and could therefore proceed more
confidently knowing that a rollback would not need any database
changes whatsoever.

That said, I still plan to remove the columns in the future when I am
beyond certain I will never need the data again but I err on the side
of caution.

This approach is somewhat vindicated by Etsy who do a similar thing,
c.f. http://news.ycombinator.com/item?id=2828415



On Fri, Mar 16, 2012 at 1:39 PM, Stephen Masters <stephen.masters at me.com> wrote:
> Taking a backup of the database is a good thing to do in case of spotting an
> issue immediately on release. But bugs with a release often don't get seen
> immediately. Restoring to a backup could potentially mean losing days worth
> of data that would be really difficult to recover, so it's worth ensuring
> that you have a means of rolling back your schema changes.
>
> There's a book out there on database refactorings, although it's not
> specifically related to how ActiveRecord does it. Their catalog of
> refactorings is here:
> http://www.agiledata.org/essays/databaseRefactoringCatalogStructural.html
>
> If the destructive aspect is just about dropping columns, then the usual
> practise is to flag those columns for deletion, and possibly rename when you
> release the code that no longer uses them. Once the new code has been active
> for a reasonable amount of time and has been shown to have no need for those
> columns, then a subsequent migration can do the drop as a stand-alone
> release.
>
> I hope that's useful...
>
> Steve
>
>
> On Friday, 16 March 2012 at 10:52, Ian Kynnersley wrote:
>
> 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
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>