When (If) to Consolidate Activerecord Migrations

When (if) to consolidate ActiveRecord migrations?

Yes, this makes sense. There is a practice of consolidating migrations. To do this, simply copy the current schema into a migration, and delete all the earlier migrations. Then you have fewer files to manage, and the tests can run faster. You need to be careful doing this, especially if you have migrations running automatically on production. I generally replace a migration that I know everyone has run with the new schema one.

Other people have slightly different ways to do this.

I generally haven't done this until we had over 100 migrations, but we can hit this after a few months of development. As the project matures, though, migrations come less and less often, so you may not have to do it again.

This does go against a best practice: Once you check in a migration to source control, don't alter it. I make a rare exception if there is a bug in one, but this is quite rare (1 in 100 maybe). The reason is that once they are out in the wild, some people may have run them. They are recorded as being completed in the db. If you change them and check in a new version, other people will not get the benefit of the change. You can ask people to roll back certain changes, and re-run them, but that defeats the purpose of the automation. Done often, it becomes a mess. It's better left alone.

Rails/MySql consolidation of migrations

Your question is a bit difficult to understand, as you're not limited to one operation per migration.

you can easily do :

class AddNameAddressAndIndexToMembers < ActiveRecord::Migration
def up
change_table :members do |t|
t.string :name
t.text :address
t.index :name
end
end

def down
change_table :members do |t|
t.remove_index :name
t.remove :name, :address
end
end
end

just reverse your migrations, delete previous migration files, run this migration and all should be well.

Now, if you mean that these are old migrations, it can be tricky because you don't want to reverse tons of migrations. But what do you want to achieve ? if you only need to deploy, use the current schema.rb with rake db:schema:dump and rake db:schema:load

Merging ActiveRecord migrations out of order

In case of conflict you should select the higher number of the two. But whatever you choose it has no impact on actual migrations.

If you choose the lower number then next time you run rake db:migrate it will change this number (to the higher one) and you will have a change in your schema.rb and no migration. It's not a problem - only your commit will be a bit strange.

Rails rake task runs all migrations that it finds and that don't have a value in schema_migrations table. And then it takes the highest migration timestamp and puts this timestamp into the schema.rb. The whole migration idea is not based on some "most recent timestamp" (schema version) but it's based on the content of schema_migrations table that contains all migration timestamps that it has already run. So through this table it guarantees that no migration is skipped.

How are rails migrations handled when merging feature branches?

Your hunch is correct - any migration not in schema_migrations will be run, and they will be run in timestamp order ascending.

In this case, the next time db:migrate is run after A merges, migration t1 will be run.

How can I convert all migration files into a single file in Rails?


TL;DR

What you need isn't a consolidated set of migrations; it's a single schema file and an optional seeds.rb file. Rails generally maintains the schema automagically when you run migrations, so you already have most of what you should need with the possible exception of seed data as described below.

Use the Schema, Not Migrations

In general, you shouldn't be maintaining a large pool of migrations. Instead, you should periodically clear out your migrations, and use schema.rb or schema.sql to (re)create a database. The Rails guides specifically state:

There is no need (and it is error prone) to deploy a new instance of an app by replaying the entire migration history. It is much simpler and faster to just load into the database a description of the current schema...Because schema dumps are the authoritative source for your database schema, it is strongly recommended that you check them into source control.

You should therefore be using bin/rails db:schema:load rather than running migrations, or run the associated Rake task on older versions of Rails.

Data Migrations

While you can use migrations to fix or munge data related to a recent schema change, data migrations (if used at all) should be temporary artifacts. Data migrations are almost never idempotent, so you shouldn't be maintaining data migrations long-term. The guide says:

Some people use migrations to add data to the database...However, Rails has a 'seeds' feature that should be used for seeding a database with initial data. It's a really simple feature: just fill up db/seeds.rb with some Ruby code, and run rake db:seed...This is generally a much cleaner way to set up the database of a blank application.

Database seed data should be loaded with bin/rails db:seed (or the associated Rake task) rather than maintaining the data in migrations.

Is it a good idea to collapse old rails migrations?

If you have your code under source control (you do have your code under source control, don't you?) then I'd say there's no real harm, provided you accept that rolling back schema changes is going to require either restoration of old migrations or brand new migrations. Just be sure you understand the implications and accept them before setting anything in stone.

Your current schema.rb can form the basis of a new single migration that will start a new set.

Be warned that if you have data manipulation operations in your existing migrations, static data loads, for example, and/or possible subsequent transformations, then these will need to be handled somewhere. It's something I've tripped over a few times...

Way to flatten Rails migrations?

This is what the db/schema.rb file is for. If you've only got structural changes in your migrations you will be able to run rake db:schema:load rather than running rake db:migrate to get the absolute structure for your tables.



Related Topics



Leave a reply



Submit