7

When starting out a new project, there are lot of changes in models that I find it easy to edit an existing migration & run db:clean or db:reset than create a new migration. I do this when app has not hit production which means I can reset/clean database without worries & I am working solo or part of a small team.

But Today, I came across the following advice in Rails Guide saying its not a good idea & discourages editing existing migrations:

Editing existing migrations is not a good idea: you will be creating extra work for yourself and your co-workers and cause major headaches if the existing version of the migration has already been run on production machines. Instead, you should write a new migration that performs the changes you require. Editing a freshly generated migration that has not yet been committed to source control (or, more generally, which has not been propagated beyond your development machine) is relatively harmless.

I want to know:

  • what potential pitfalls I can run into ?
  • Does those pitfalls apply in my case(development stage,working solo)?
CuriousMind
  • 33,537
  • 28
  • 98
  • 137
  • why dont you self-experience it? :) – Amol Pujari May 30 '12 at 08:39
  • I am already doing it :) – CuriousMind May 30 '12 at 09:57
  • this reminded me, that once we had used global constants in migrations, these constants were defined in some constant.rb file, which later edited by some one :) So point is, always use hard coded values in migrations, no variables, no constants – Amol Pujari May 30 '12 at 10:01
  • Agree! However, if I just created a model & want to change it, I find it easier to edit the migration directly. No point of leaving audit trail at early into the process – CuriousMind May 30 '12 at 10:05

4 Answers4

10

If you are working with a team and you committed the migration then NO.

If it is only on your local environment then just create a new migration fixing what you need. You can drop tables\columns and do what you need.

Since you clean the db and reset it, then everyone will be doing the same or they will have issues if they try to migrate.

Sully
  • 14,672
  • 5
  • 54
  • 79
1

I'm working on a web-app in development mode. Although I am working alone, it's best practice to use migrations to modify the database. It might leave a trail of modifications, but you can see the evolution of your database structure. In the long run, you will become faster at resolving db issues with migrations.

C. S.
  • 805
  • 6
  • 6
  • 1
    Would you please add a bit more substance to help the OP, such as what pitfalls and/or how to learn what is 'best practice'? Thanks! (reviewing) – Gayot Fow Jul 08 '13 at 23:11
0

Database migrations are a tool. Like any toolbox the most important thing is to understand what it is good for, how to use it, and why to use it that way.

  • Live Site: In a live site you can't simply use rake:db reset because clearly you need all that data
  • In collaboration: You need to maintain migrations in consistency with other developers. What if they have entered data into their database (for whatever purpose) and simply mixed in your code. You've now completely foobared their efforts and they will be compelled to reset their entire database
  • Rake db:rollback : Once you've modified the code you'll have to reset, now you can't run rollback.
  • It's a bad habit: In the majority of cases the polite manner in which to do this is to create a new migration. It is better to be in the habit and of the mindset to be able to quickly and efficiently create new migrations.

I'm not actually telling you not to do it. These are just the major points as to why not do as I see it. I most cases if you are alone, or especially if you are just forming up your project (and may not immediately realize how you want the database to look/work playing around with them directly may be most efficient. It is important to understand the why and wherefore's before you going mucking about against best practice.

falonofthetower
  • 98
  • 2
  • 6
0

As soon as you've committed a migration to git, as long as its not a data destroying or CI crashing thing, you should not change it. This is axiomatic to the whole concept!

The problem is, once the migration is applied, its not run again, and if you have to wind back to it, you're risking unintended data-loss. You should always just create a new migration.

There is one exception, and its a tricky one, to do with removing dependencies. One of the problems faced by migrations that involve third parties in limited circumstances ORMs is that the dependencies are an either/or thing. They either exist or they don't. So if at a certain point you add a dependency that you then create foreign references to from your model, and stash that in a migration, then later remove that dependency, when you run the migrations from scratch, the dependency that is linked to in the migrations will fail because the target of the foreign key simply doesnt exist anymore. Its a doozy of a problem, because in that situation you will in fact need to edit the old migrations to remove the foreign keys, but you also need to have a migration for the existing installations to remove the key.The general patern here is if your migration system is scriptable, throw a check in to see if the key exists and then, and ONLY then, remove the key, otherwise, skip the removal. Keep in mind, by the way, that a try {} except {} type structure might be the wrong choice here, because some ORMs roll back the transactions lined up to write when an exception of any sort is raised to avoid corruption.

So generally, no please dont edit existing migrations, but if its in those limited situations where externalities dictate a requirement, proceed with very delicate care.

Shayne
  • 1,571
  • 1
  • 16
  • 20