schema.rb messed up due to migrations in other branches

Question

Currently I'm working with a huge rails application and multiple branches with each a new feature for this application. It happens a lot a feature will require migrations, which shouldn't be a problem until you merge it with master: schema.rb got updated with the information of your dev database!

To clarify:

1. Branch A has migration create_table_x
2. Branch B has migration create_table_y
3. Branch A adds another create_table_z and runs db:migrate
4. You want to merge Branch A with Master and you see table_x, table_y and table_z in the schema.rb of Branch A.

It's not an option to reset+seed the database before every migration in a branch or create a database per branch. Due to the huge size of 2 GB SQL data, it would not be workable.

My question:

Is it really required to keep schema.rb in the repository since it gets rebuilt every migration?

If so, is it possible to build schema off the migrations instead of database dump?

Answer 1

you should keep the schema within your repo. running the migration will fix merge conflicts within your schema.rb file for you. my simple take on your questions

1. Is it Required? not really, but good practice.

"It's strongly recommended to check this file into your version control system." -schema.rb

1. It is possible? yes but you may want to ask yourself if you really save any time by doing so, either manually or building the schema off your migrations elsewhere and pushing it in.

you ge tthe added benefit of using

rake db:schema:load

and

rake db:schema:dump

http://tbaggery.com/2010/10/24/reduce-your-rails-schema-conflicts.html

Answer 2

Keeping schema.rb in the repo is important, because you want a new developer (or your test environment) to be able to generate a new database just from schema.rb. When you have a lot of migrations, they may not all continue to run, especially if they rely on model classes that don't exist, or have changed, or have different validations in effect than when the migration was first run. When you run your tests, you want to dump and recreate your database from schema.rb, not by re-running all the migrations every time you run the full test suite.

If you're working on two different feature branches simultaneously, and changing the database structure in both, I think schema.rb is the least of your problems. If you rename or remove a column in branch B, branch A is going to break whenever it references the old column. If all they're doing is creating new tables, it's not as bad, but then you want schema.rb to be updated when you merge from master into A, so that A doesn't try to run the migration a second time and fail because the new table already exists.

If that doesn't answer your question, maybe you could explain your workflow a little more?

Answer 3

Fresh Temporary DB as a quick workaround

For example, do the following whenever you need pretty db/schema.rb on particular branch:

1. git checkout -- db/schema.rb
2. switch to the different development database, i.e. update config/database.yml
3. rake db:drop && rake db:setup
4. rake db:migrate
5. commit your pretty db/schema.rb
6. revert changes in config/database.yaml