Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How are rails migrations handled when merging feature branches?

Tags:

In rails 3, how does the db:migrate task determine which migrations to run?

Consider the following use case:

  • developer A creates a migration at timestamp t1 in his own feature branch
  • developer B creates a migration at timestamp t2 in his own feature branch
  • developer B merges his branch, db:migrate is run on the server
  • developer A merges his branch

Since t1 is earlier, does developer A's migration get run or not?

I noticed the schema_migrations table, and I'm wondering if any migration that has not run yet will be run.

like image 720
Ovesh Avatar asked Jul 03 '13 08:07

Ovesh


People also ask

How do you manage migrations in a project with multiple branches?

Is there a good way to manage Migrations in a project with multiple branches? One way would be to merge, then delete all migration-files created while the branches were separate, and then create one new migration file that holds all changes from the time the branch was created until it was merged back in.

How does rails migration work?

A Rails migration is a tool for changing an application's database schema. Instead of managing SQL scripts, you define database changes in a domain-specific language (DSL). The code is database-independent, so you can easily move your app to a new platform.

How does rails keep track of migrations?

Every time a migration is generated using the rails g migration command, Rails generates the migration file with a unique timestamp. The timestamp is in the format YYYYMMDDHHMMSS . Whenever a migration is run, Rails inserts the migration timestamp into an internal table schema_migrations .

Are rails migrations run in a transaction?

On databases that support transactions with statements that change the schema, migrations are wrapped in a transaction. If the database does not support this then when a migration fails the parts of it that succeeded will not be rolled back. You will have to rollback the changes that were made by hand.


1 Answers

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.

like image 71
Chris Heald Avatar answered Sep 22 '22 12:09

Chris Heald