Long-Term Rail Migration Consolidation

Question

I am working on a project that has collected hundreds of migrations, and I'm not sure what to do with them in the long run. I believe that nothing hurts them, but it seems strange to keep a bunch of old files for incremental migrations, some of them create tables that are subsequently deleted.

So far I have seen three possibilities:

• Leave them alone. They don't hurt anything.

• Just delete them. I don’t see much harm in this, since the new developer would probably start by loading the schema anyway, not migration.

• Delete them all, create a new one with a timestamp corresponding to the old merge, and create a new merge from your schema. It seems very clean, but I'm not sure who actually uses it.

I tend to just delete them, but I'm curious if there is a big gap that I am missing.

Answer 1

In my opinion, as soon as each project database, especially production, at least on version 201xxxxxxxx, it should be good to remove migrations to this version. They are no longer technically necessary.

After that, if you want to play archeology with the history of the database, you can still use your version control system.

With Git , you can use the following commands to quickly view the past:

git log --name-only db/migrate/ #to list commit involving migrations + migration filename git show xxxxx db/migrate #to see the code of commit xxxxx migration(s) 

In addition, you can view the schema.rb repository schema.rb , identify the commit, and see the corresponding migration content using the command above.

If you prefer to have a lighter db/migrate and use version control, I would fix it a bit.

If it would be more convenient for you to have all the available migration history, since it is easier to view, I would choose option 1.

Note : it is very likely that old migrations do not make sense with the current application code. For example, some migrations may refer to a class or methods that no longer exist. Using version control to validate an application while writing a migration can also avoid some confusion.

Answer 2

Personally, I am inclined to option 1: As a rule, it is true that at some point in any project, the scheme is important, and migration is just curiosity, but you are right when you say that they do not hurt anything, Theoretically, old migrations can be useful for those who wanted to go back and see how the database was organized at some point in the past.

I don’t know the serious errors when deleting them, but I also don’t see the benefits for this, unless this saves time by scrolling through them when you want to edit a new migration.

I don’t think that trying to collect a single migration, which duplicates the scheme, is useful - this is additional work and that the scheme is anyway.

Answer 3

If you are working on a project large enough long enough, the time will come when you will look at all these additional migrations with contempt and wonder how many can exist.

You think to yourself: "Just delete them ... they do nothing." This is a perfectly logical and normal thinking process (especially as a Rails developer, we just want to minimize code and make things effective!), But don't let the dark side tempt you.

By deleting the migration, you delete the historical record of your application data model and, even worse, the logical path that you used to go to the current model. This story will help you remember why you did what you did and did not do what you did not.

Yes, we were always guilty of removing migrations. But you must resist the temptation, as the net benefit will be only a few kilobytes and a cleaner migration folder.

Remember: Those who remove migration are doomed to repeat them!

Answer 4

In one of our previous projects, we dropped all migrations, created a new one that trims the schema_migrations table using manual sql, and then copies the contents of db / schema.rb. Of course, this migration is irreversible, but it allowed us to get rid of hundreds of old useless migrations, but still can recreate db not only from the db scheme, but also from migrations.