re: Data migrations
There’s a gem for that! (I happen to be its author)
By separating your schema migrations from data migrations, you can
separate the concerns easily. (And, for example, not run your data
migrations in a test or QA environment if you so choose)
Also schema migrations necessarily mean you have to restart your app
(downtime), and data-only migrations can be run while the app is
running.
Almost every production-scale website with traffic I’ve worked on has
needed data migrations at some point. While making everything a data
migration is costly to developers, doing it for batch imports makes
perfect sense. Let’s say your company acquired another company, and you
wanted to import the other company’s data. Yes, you could reasonably use
a rake task, but data migrations make it easy to keep track of and
ensure that all environments get the same treatment.
Although I understand the sentiment that it “smells bad” (and indeed,
running a large data job in a schema migration can take a while, leaving
your site down during the migration), the purpose of my gem is to
address a real business need in a way that isn’t so smelly to
developers. In the context of this discussion, I’d call it a
middle-ground approach.
-Jason
On Nov 14, 2014, at 9:18 AM, [email protected] wrote:
Hi Colin,
Thanks for your response. I totally agree with you. Do you or anyone else have
experience with these kind of data content migrations going bad? Basically, the
only argument I can provide the team is that it “smells” bad, the intent of
migrations seem to be for data structure, not content (other than reference data
or an initial admin user), and all migration documentation/examples only show DDL
type statements.
Thanks.
Jason Fleetwood-Boldt
[email protected]
All material © Jason Fleetwood-Boldt 2014. Public conversations may be
turned into blog posts (original poster information will be made
anonymous). Email [email protected] with questions/concerns about
this.