Blog post: strategies for defensive Rails migrations

[Cory Kaufman-Schofield]

Figured this might be of interest  the group. I wrote a blog post detailing some strategies for writing better Rails migrations (anticipating exceptions, columns that already exist, etc.). Here's the post:

http://mindlikewater.io/defensive-migrations

Would love to hear any other tips people have!

Cory

[Julien Vanier]

Nice article Cory.

I especially like the local AR models for migrations. It helps to avoid issues with validations and callbacks that may bomb when models have changed since the migration was first written.

Has anybody on the list ever felt the need to first run a migration then write code that uses the changed columns in several deploys like in this post? http://blog.codeship.com/rails-migrations-zero-downtime/

Julien

--
You received this message because you are subscribed to the Google Groups "Ann Arbor Ruby Brigade" group.
To unsubscribe from this group and stop receiving emails from it, send an email to a2rb+uns...@googlegroups.com.
To post to this group, send email to a2...@googlegroups.com.
Visit this group at http://groups.google.com/group/a2rb.
For more options, visit https://groups.google.com/d/optout.

[Cory Kaufman-Schofield]

Julien,

Thanks!

I think the suggestions in the article you mentioned are good practices.  Often I'll "deprecate" attributes instead of renaming them by adding a new column and converting writes to update the new column before I drop the old one.

I'm actually working on something that does this right now: I need to convert a boolean attribute into an enumerable attribute (stored as a string since we're sadly using MySQL instead of Postgres) so I've created a special setter that takes a boolean value and sets the appropriate string value.

Usually I'll leave the deprecated attribute in production for a few days or weeks and make sure things are stable before actually removing it.

Cory