Editing Existing Rails Migrations is a good idea?

问题:

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)?

回答1:

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.

回答2:

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.

回答3:

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.