Editing Migrations

Posted by Luke Francl
on Wednesday, January 20

I have a confession to make: when I’m starting out a new project, especially if it’s a small team, I like to edit my migrations.

At the beginning of a project there are always a ton of changes in how models are defined and how they relate to one another. I find it so much easier to edit migrations and keep these initial declarations compact than to write new migrations for every piddling change.

The downside is an increased communications burden—people need to know they need to run rake db:migrate:reset when migrations change. And, of course, once you’ve got real data in production, you can’t do this.

But at the beginning of a project, I like to edit my migrations.

Comments

Leave a response

  1. Mike MondragonJanuary 20, 2010 @ 10:46 AM

    I totally do this. A related pet peeve is coming fresh into an existing project and having db:migrate fail when executed on a new db.

  2. Dan WeinandJanuary 20, 2010 @ 10:59 AM

    I’m with you. No point in leaving a huge audit trail for changes made long before anything was ever deployed. And to go with Mike, I generally think it’s a good idea for developers to re-migrate from scratch even after you stop editing migrations. That way you ensure a consistent database state across all developers.

  3. Dan WeinandJanuary 20, 2010 @ 10:59 AM

    I’m with you. No point in leaving a huge audit trail for changes made long before anything was ever deployed. And to go with Mike, I generally think it’s a good idea for developers to re-migrate from scratch even after you stop editing migrations. That way you ensure a consistent database state across all developers.

  4. TonyJanuary 20, 2010 @ 11:02 AM

    The problem is when dudes do this later in a project and then fail to tell everyone else to reset. It’s all about communicating. If your coworkers don’t bother to say, “hey, re-run this migration,” then you have other problems!

  5. jeemJanuary 20, 2010 @ 11:18 AM

    No big deal. I use rake db:migrate:redo and tune the latest migration all the time.

  6. Tore DarellJanuary 20, 2010 @ 12:18 PM

    Nothing wrong with that. Everyone does it.

  7. Daniel HuckstepJanuary 20, 2010 @ 01:16 PM

    You’ve got my vote too. Editing migrations is no big deal before things are live.

  8. daeltarJanuary 20, 2010 @ 01:36 PM

    Yes, it helps keep things reasonably simple.

  9. David BackeusJanuary 20, 2010 @ 01:59 PM

    Starting out with db:migrate is deprecated to me in favor of db:setup. Which will first load the schema.rb, then migrations, then the seeds.

    Since you then always have a clean schema.rb fiddling with a high number of migrations becomes less of an obstacle.

    I sometimes mess about with migrations but only in the scope of one commit. I wouldn’t edit migrations after they’ve been checked in to version control.

  10. Steve St. MartinJanuary 20, 2010 @ 03:25 PM

    Yeah, I totally do this too, especially on the latest migration rather then having 100 migration files.

  11. Lar Van Der JagtJanuary 20, 2010 @ 10:02 PM

    I’ve been doing this for a while as well. I usually roll up the tasks db:drop, db:create, db:migrate, db:seed & db:test:prepare into one rake db:cycle task.

  12. Daniel FischerJanuary 23, 2010 @ 12:42 AM

    Yep, I do this too. Don’t worry too much :)

  13. Thomas R. KollJanuary 24, 2010 @ 09:19 AM

    I that do occasionally too when the migration didn’t run on production yet. Otherwise it must be a new migration.

    But since I’ve moved on to MongoDB for new projects there are almost no more migrations to write.

  14. JonasJanuary 24, 2010 @ 09:48 AM

    The number of times I’ve been bitten by someone having changed “just that little thing” in an old migration… If you’re working on your own, then by all means, who cares! But if you’re working on a team, if you’re working with me, don’t change checked in migrations, or I will hate you.

  15. GravisJanuary 31, 2010 @ 07:46 AM

    We all like to edit our initial migrations :) That’s why I’m using a lot the automigrations plugin. When the project is ready for production, I use the plugin to create a first valid and unique migration, pretty handy !