Rails changes schema.rb for no reason

Question

Each time I run rake db:migrate rails, it decides to modify the schema.rb file. In some cases, this is quite reasonable, but in some other cases it seems that he does it for no reason. The thing I'm confused about is when I migrate a new migration and a new version of schema.rb from git, and then run rake db:migrate . Since a new version of the schema.rb file came with this migration, I should not update schema.rb. However, the rails still change it every time. When this happens, I find incredibly stupid changes, such as:

 add_index "my_table", ["column1", "column2"], :name => "index_on_some_columns" 

to

 add_index "my_table", ["column2", "column1"], :name => "index_on_some_columns" 

When this happens, I just run git checkout db/schema.rb and continue my life, but it infuriates me. Is there a reason why this is so, and how can I stop it from doing this?

EDIT: Here's an excerpt from diff

 @@ -165,12 +165,11 @@ ActiveRecord::Schema.define(:version => 20130206001907) do t.column "updated_at", :datetime - t.column "coordinates", :point, :srid => 4326 @@ -200,15 +199,16 @@ ActiveRecord::Schema.define(:version => 20130206001907) do t.column "something", :boolean + t.column "coordinates", :point, :srid => 4326 + t.column "random_string", :string t.column "remote", :string - t.column "random_string", :string end - add_index "my_table", ["id", "foreign_id"], :name => "index_active_my_table_on_foreign_and_id" - add_index "my_table", ["id", "active"], :name => "index_my_table_on_active_and_id" - add_index "my_table", ["id", "content_modified_at"], :name => "index_my_table_on_content_modified_at_and_id" + add_index "my_table", ["foreign_id", "id"], :name => "index_active_my_table_on_foreign_and_id" + add_index "my_table", ["active", "id"], :name => "index_my_table_on_active_and_id" + add_index "my_table", ["content_modified_at", "id"], :name => "index_my_table_on_content_modified_at_and_id" 

Answer 1

Since a new version of the schema.rb file came with this migration, I should not update schema.rb.

This is inaccurate.

Each time Rails starts a migration, it updates the schema.rb file, using the database as the source. It does not look at the existing schema.rb file, it just uses the information from the database and overwrites it.

It seems that the real problem is that when performing the same migration in two different environments (different combinations of Ruby, Rails, MySQL, operating systems), different results may occur when creating the schema.rb file.

The solution is to make sure that everyone who checks the code uses the same software versions as much as possible. And if this is not possible (because it is the difference between Windows and Linux against the Mac, and you do not want to change your OS), you just have to deal with the inconvenience.

Answer 2

For me, the solution was first made by rake db:schema:load . And than rake db:migrate stopped changing me schema.rb no reason.

ATTENTION: rake db:schema:load will delete ALL of your existing data and recreate the database against the existing schema.rb.