When (if) to consolidate ActiveRecord migrations?

Question

When I navigate through iterations in my application *, I accumulate migrations. Currently, there are 48 such files, covering about 24 months of activity.

I am considering entering the current schema.rb and creating a baseline.

I am also considering the possibility of removing (taking into account source control, of course) existing migrations and creating a beautiful new brilliant migration from my current scheme? Migrations tend to resemble characters, but rake db:schema:dump uses strings: do I care?

Does that seem reasonable? If so, in what interval does such an exercise make sense? If not, why not?

And I missed some (rake?) Task that will do this for me?

* In my case, all applications are based on Rails, but everything that uses ActiveRecord migrations seems to answer the question.

Answer 1

Yes, that makes sense. There is a practice of consolidating migrations. To do this, simply copy the current scheme into the transfer and delete all previous migrations. Then you have fewer files to manage, and tests can run faster. You need to be careful, especially if you have migrations that automatically start during production. Usually I replace the transfer, which, as I know, everyone started with a new scheme.

Other people have slightly different ways of doing this.

I did not do this at all until we had more than 100 migrations, but we can hit it after several months of development. However, as the project matures, migrations occur less and less, so you may not have to do it again.

This is contrary to best practice: as soon as you check the transition to the original control, do not change it. I make a rare exception if there is an error in it, but it is quite rare (maybe 1 out of 100). The reason is that when they went out into the wild, some people may have launched them. They are written as completed in db. If you change them and check in the new version, other people will not be able to use this change. You can ask people to discard certain changes and restart them, but that defeats the goal of automation. Running often, it becomes a mess. It is best left alone.

Answer 2

I think there are two types of migration:

• the ones you did during development / development because you changed your mind what your db should look like;

• the ones you did between releases reflecting some behavior changes.

I will get rid of the first type of migration as soon as I can, since they actually do not represent working releases and retain the second type, so it is theoretically possible to update the application.

About characters versus strings: many argue that only strings should be used in migrations: characters are intended for "descriptors" for objects and should not be used to represent names (in this case, the names of columns and tables). This is just a stylistic consideration, but convinced me, and I no longer use symbols in migrations.

I read another example of the use of strings: "ruby characters - memory leaks", which means that when creating a character, it never gets to the whole lifetime of the application. This seems completely pointless to me, since all your db columns will be used as characters in the Rails (and ActiveRecord) application; the migrating task will also not last forever, so I do not think this item makes sense.

Answer 3

Having a large number of migrations is good. In combination with your version control system, they allow you to see that the developer has made changes to the database and why. It helps accountability. Removing them just makes it a big hassle.

If you really want to quickly start and start a new database, you can simply load the circuit using rake db: schema: load RAILS_ENV = your_environment, and if you want to quickly install your test database, you can simply use rake db: test: preparation

If you really want to consolidate your migrations, I would create a new migration that checks if the last migration in your set has been performed (for example: has a column been added?) And if not, it will burn. Otherwise, the migration will simply add itself to the schema table as completed so that it does not try to start again.

Just let us know what you are doing with the rest of your team so that they understand what is happening, so that they do not blindly shoot from the db rake: migrate and ruin what they already had.

Answer 4

The top of schema.rb declares:

 # This file is auto-generated from the current state of the database. Instead of editing this file, # please use the migrations feature of Active Record to incrementally modify your database, and # then regenerate this schema definition. # # Note that this schema.rb definition is the authoritative source for your database schema. If you need # to create the application database on another system, you should be using db:schema:load, not running # all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations # you'll amass, the slower it'll run and the greater likelihood for issues). # # It strongly recommended to check this file into your version control system. 

I have to endorse what [giorgian] said above about different migrations for different purposes. I recommend cleaning up development-oriented migration along with other tasks that you perform when you submit the release. This works well for me, for myself, and for small teams. Of course, my main application is located on top of and between two other databases with their own schemas, which I have to be careful about, so we use migration (not schema recovery) for the new installation, and those who need to survive release development.

Answer 5

Although I'm sure everyone has their own practices, there are several rules that are implied by how the migration system works:

• Never make changes to migrations that might have been used by other developers or previous deployments. Instead, make an additional migration to adjust the settings as needed.
• Never put model dependencies at the migration level. The model may be renamed or deleted at some point in the future, and this will prevent migration. Keep migration as autonomous as possible, even if it means that it is fairly simplistic and low-level.

Of course, there are exceptions. For example, if the migration does not work, for some reason a fix may be required to update it. However, even then, the nature of the changes caused by migration should not change, although their implementation may be.

Any mature Rails project is likely to have 200 to 1000 migrations. In my experience, it is unusual to see a project with less than 30, with the exception of the planning stage. Each model, after all, usually needs its own migration file.

Collapsing several migrations into one of them is a bad habit to enter while working on a developing piece of software. You probably don’t minimize your version control history, so why bother with the history of the database schema?

The only case when I see that it is reasonably practical is that you open an old project to create a new version or selection and do not want to transfer with a lot of migrations.

Answer 6

You must not remove the migration. Why create extra work?

Migrations are essentially a set of instructions that determine how to create a database to support your application. As the application is created, the migration records the iterative changes made to the database.

IMHO, periodically updating the baseline, you make changes that may introduce errors / problems into your application, creating additional work.

If you mistakenly add a column and then need to delete it after a while, just create a new migration to remove the extra column. My main reason is that as a team, you don’t want your colleagues to continue to restore their databases from scratch. With this simple approach, you (and they) can continue to work iteratively.

On the side, when creating a new database from scratch (without any data), migrations tend to work very quickly. The project I'm currently working on has 177 migrations, this does not create problems when creating a new database.