Since topic name covers such a broad functionality, I’ll add my little annoyance with migrations here as well. A lot of people say that data migrations are an anti-pattern with existing database migrations functionality in rails. While there are couple of gems that address that. It would be nice if…

Think part of the pushback against changing data in migrations comes from relying on existing ActiveRecord code to change data instead of writing raw SQL. Fun part is, migration breaking changes to that code don’t show up until somebody needs to run migrations from scratch.

Yeah, we have very strong rules about that, never lean on models app code during migrations, use raw sql, keep migrations stand-alone and stable over time

The “raw SQL” idea is intriguing and I’ve never heard it before. I like it a lot, as someone who has previously been in camp “no data migrations, they will have sneaky app-breaking consequences down the line.” I’m moving this topic to its own thread where it can get proper attention.

I much prefer writing data munging scripts in Ruby though. Writing non-trivial UPDATEs in SQL is intimidating. Defining a new ActiveRecord class in the migration file helps expose the power of AR without something breaking down the line, but testing the logic in that class is tricky.

I personally make a practice of deleting my test database from time to time, and then running migrations up from the start. It tends to catch these sorts of things very quickly. Our CI also drops the test database before each run, and so “works on my Mac” isn’t a good excuse for anyone. Walter

[image] ferngus: Defining a new ActiveRecord class in the migration file helps expose the power of AR without something breaking down the line, but testing the logic in that class is tricky. Can you go more into this approach? I think I understand what you mean, and it sounds pretty cool, but…

Something like: class Migration < ActiveRecord::Base self.table_name = 'schema_migrations' end Migration.last #should return the last entry in schema_migrations as a Migration object Basically an AR class which only exists in the migration file. self.table_name= allows it to manage any existing…

[image] DHH: They’re intended to be moments in time. Not to be replayable forever. The stable unit is schema.rb (or structure.sql). Then I am sorry to say this but my experience is exact opposite of those intentions. schema.rb was never stable unit for us and during lifetime of our applicatio…

How do you manage data migrations that do not fill on those constrains? One case I had recently: I had a field with 2 possible values per user that for different reasons we had to transform on a table that had around 3-4 rows per group of users. That transformation was not trivial and not only n…

Patterns for "data-only" Rails migrations

A May Of WTFs

DHH (DHH) May 22, 2020, 5:33pm 10

We mix data and sql statements in migrations all the time at Basecamp. This is what migrations were designed to do! They’re intended to be moments in time. Not to be replayable forever. The stable unit is schema.rb (or structure.sql).

Topic		Replies	Views
Approaches to data migration on Rails applications rubyonrails-talk migrations	14	2013	September 27, 2024
Migrations Shortcomings rubyonrails-talk	11	158	October 15, 2006
how to share variables in data migrations (up/down) rubyonrails-talk	26	348	March 5, 2010
Rake tasks for development and testing rubyonrails-core	23	1347	December 8, 2007
In the need for separating data migration from schema migration rubyonrails-core	6	786	April 15, 2015

Patterns for "data-only" Rails migrations

Related topics

More Resources