Usefulness of db migrations rollback

Question

Hi,

Many people talking about db migrations, especially about its rollback possibility.

I doubt, whether it is useful at all, because schema of db and model are tightly connected with application logic (MVC).

Suppose i've done rollback of some migration. And what ? The application will not work, because its logic fully relies on db.

What are the use cases of rollback ability for db migrations ?

---

Update 1

The main question

Why the rollback is presented as a feature, when i need to change the code ?

I don't create the migrations, like "add_another_field_to_table". Instead, each migration file fully describes each table in DB. When i need to change something in my DB, i just change the migration file, but don't roll it back.

Really, if i rollback the migration, it does't brings me back in time, like a version control does. I have a lot of work, when changes are planned and rollback gives me nothing.

Answer 1

The point of rollback is that you rollback code and DB at the same time. The scenario is you upgrade your code and your DB on your production server, then you find a bug and you really need to go back. So rollback your code and use your down migration to roll back your DB.

Answer 2

Don't really understand your problem, but i try to explain a bit the rollback. You do rollback if you want to undo the changes by the respective migration. This means that the database will be modified, and also your schema.rb will be automatically regenerated. When you do this probably you want to remove the referencing code too. For example if you removed a field from the model, probably you don't want to refer to that attribute in your code. If you try to access then will gives you undefined attribute exception. That's it. Can become a bit cumbersome to rollback for example if you created some model 10 migrations before, and you want to change some fields. It's better to create a new migration and modify there, instead of rolling back to the respective migration.

Update 1

Read your update, and i think yo don't use the main advantage of migrations, the flexibility. But your solution gives more overview of the database situation. If you like to do that way, I suggest the following steps in order.

1. Roll back to the respective migration.(rake db:migrate VERSION=XXX, I like better rake db:rollback STEP = 2 for example, rolls back 2 migrations, STEP optional)
2. Make your changes
3. Migrate your database to update all the tables, and get to current migration version.(rake db:migrate)

This feature don't affect your models or something, just changes the migration file, regenerates your schema.rb and changes the database structure, nothing else. Can't do code rollback like with version control system, and don't really has sense to do something like that. You have to take care about not using removed fields. Rails has automated mapping between database fields and model attibutes, for example if you have an user_id in your comment table, you can call it as an attribute in your model, comment_instance.user_id. Hope this make sense.

Answer 3

What are the point of Up migrations?

1. You create table structures.
2. You code round it, it works well.
3. You put site into production, everyone is happy.
4. Oh, wait, they want a new feature that involves adding a column to an existing table.

How do you handle this? You have to add a column to your development tables, test code, update live site without forgetting to update live DB at the same time (cos if you do there will be big errors) And also remmember to preserve existing live data. This aspect of DB management can be a real pain without a nice managed solution like rails has.

So ...

1. Code a one line migration that adds a column
2. Run migration on dev copy, scehma.rb will update
3. Code new features, if you need to check DB schema use schema.rb NOT migration files.

Now your ready to release on production ....

1. Update code on production
2. Run migrations on production. Rails will automatically work out what needs to be applied and do it for you!

Sure, with you adding one column it's not that confusing to do it yourself.

But what if there were 3 programmers all adding migrations? What if you have many live sites, all at different versions? Is that live site 2 or 17 migrations behind? What do I have to do to get the DB up to the latest code, whilst preserving live data? Can you see how this would very quickly get confusing to deal with?

Rails migrations (and practically every migration system works on the same principles) are designed to make updating DB structures really easy. Well worth using properly.

Answer 4

Consider a scenario where you use capistrano to deploy your site and create timestamped snapshots of each deployment. Using the timestamp on the folder and your migrations, you could identify which versions of the code and schema go hand in hand and perform a rollback.

A git repository would give you similar options.

Of course, the real problem is that once users of a site start adding data, that will potentially get purged too, unless you back it up before a rollback and painstakingly restore it at a later date.

Answer 5

I've found that rollbacks are only useful if they are done locally, ie while you're working on a new bit of code. Once a migration has been committed into your version control system, if you realise there was a mistake then it doesn't really work to roll back the migration because other developers will have pulled the migration down and run it, so you'd need to tell them to roll back as well - this is too difficult to manage and also makes you look incompetent :)

Better in this situation to just do another migration to fix the problem, then everyone (including your production server) just sticks with the pull & migrate system.

Answer 6

I use migration rollback locally with rake db:migrate:redo while working on migration code and before final commit.