Rails migrations was a game changer when it came to updating database schema, but one think I've noticed is that I've never used the migration down facility even though I still code them out like an automaton. I'm thinking of quitting with them because instead of writing migrations down, I write new migrations forward to reverse whatever it was I would reverse with a migration down. Has anybody quit writing migration downs?

If you do a lot of simultaneous development by different people in different branches, down migrations are essential. As you change branches, you run the down migration to get your schema back to baseline. (Look at tpope's hookup gem for automating this.)

People who don't write down migrations infuriate me as it inevitably leads to broken schema files.

What people don't know is that change_table completely fucks you over with an IrreversibleMigration. So it's not entirely peoples' fault, Rails Core also owns some of the blame for lazy implementations.

I guess what I'm saying here, is in all probability, your migrations are already fucked. Experienced devs, know how to mitigate these issues. However it's really the APIs fault in my opinion.

Allow me to exacerbate the the issue by contrast with curator's implementation of migrations, a world where you test your migrations, it's beautiful.

I'm a strong believer that migrations should happen on-the-fly, because not all data is reused or needs to be touched on.

My experience is that I don't find any cases where migrations down are useful and that I don't like the amount of effort it takes to write them. I suspect they are brittle because you have to write a perfect reverse of the migration up, one mistake and you have to take a lot of time to untangle them. Better to just write migrations forward only.

Rails will figure out how to reverse your original migrations through the "change" method instead of "up" and "down". The only case where you need to to go back to using "up" and "down" is if you have your own SQL queries.

An app's migrations should represent a way to build up the current database structure. If I run all the migrations on an empty database, I should end with a valid, up-to-date database schema. (Really, though, for performance, you'd actually just load the schema. I'm just talkin' semantic value.)

So, write new migrations to undo old migrations if the app no longer uses the tables/columns/whatever defined in the old migration, even though it used to. Migrate down when you want to change the state of your current database, e.g., to undo a stupid migration that you're about to delete or when the new feature breaks in production or whatever.

So, write migrations to change the database spec, and migrate up/down to change the database itself.

You shouldn't count on migrations being valid & runnable after a sufficient amount of time though. We've got 800 migrations in our project right now and they're not runnable from scratch, never bothered to figure out why.

When you need to get a working DB from scratch you load the schema, I don't understand why you'd want to run migrations.

Migrations shouldn't ever stop working, but, in the real world, sometimes people cut corners and it happens. I'm mostly talking about semantic value: migrations represent the database schema's history, and the full set of migrations, when applied, oughta yield the current schema—that's not the definition of migrations, or even what they're good for. Instead, it's just a special property of migrations that might help a new developer better understand their purpose and what does or doesn't deserve its own brand new migration.

I agree that if they're not runnable from scratch it's due to sloppiness or having to cut corners, something I've had to do in all production projects.

I'm not sure if I'd tell a new hire to read the migrations from scratch though, maybe it depends on what kind of a project it is. Our project started off as something completely different, there are about 300 migrations that are unrelated to what the project currently is.

If there's a clear vision from the start I suppose they'd make for a good quick history lesson though!