Some questions on db migration tasks (rake db:migrate)
- Does it make sense to rename the file names, if there is a spelling mistake.
(e.g. CreaetFoos.rb to CreateFoos.rb) - I created a migration script (say version ‘3’) by mistake during the dev process and I would like it to be removed from git. What if I had already migrated to be at the current level of ‘6’, should I just rollback till ‘2’, remove migration script corresponding to ‘3’ from git and re-run migration scripts. Will schema_migrations hold the right data in this case?
- I would like to create a migration script during the dev process, but I don’t want this to be considered as part of the migration script unless I call it complete (i.e. I don’t want other developers to use a incomplete migration script which is checked into git). How do I handle this?
A multi-part question! Let me answer them in the proper parts.
[Question 1] Does it make sense to rename the file names, if there is a spelling mistake.
If it bothers you that much, yes. It would also bother me too.
[Question 2] [Wall of text about removing a migration]
Once a migration has been committed to your version control system, it should remain untouched. If it’s modified, then you and other developers would need to roll it back and forward in order to get its changes again. It would be much better if you were to never touch old migrations and to fix any issues in new migrations. There are exceptions to this rule, which will be obvious when you encounter them.
Such as migrations that drop entire tables by accident.
[Question 3] Handling of migrations committed to version control
It’s best practice to work in your own branch if you’re going to be committing work that is incomplete. By doing this, you will leave the main branch (“master”, probably) pristine and complete, allowing for other developers to continue on their own work.
Once you’ve got that migration sorted, then you will merge that branch back into master.