rails changes schema.rb for no reason

Question

Everytime I run a rake db:migrate rails decides to change my schema.rb file. In some cases this is completely reasonable, however in some other cases it seems that it's doing it for no reason. The case I'm confused about is when I pull a new migration and a new version of schema.rb from git, and then run rake db:migrate. Since the new version of the schema.rb file came with this migration, I shouldn't be updating schema.rb. However, rails still changes it, every time. When this occurs I find incredibly silly 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 simply run git checkout db/schema.rb and go on with my life, but it irkes me to no end. Is there a reason why it does this, and how can I stop it from doing this?

EDIT: Here's an excerpt from a 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"

In multiple cases a migration said `add_index :my_table, ["column2", "column1"]` but the schema.rb supplied via git had the opposite ordering: `add_index "my_table", ["column1", "column2"]`. It seems to be consistent, but now I'm wondering how the opposite ordering of columns ever made it's way into code. This may be naïve but could this have something to do with working with both linux/mac? — wesdotcool, Feb 12 '13 at 22:16

score 7 · Accepted Answer · answered Feb 12 '13 at 22:36

Since the new version of the schema.rb file came with this migration, I shouldn't be updating schema.rb.

This is inaccurate.

Every time Rails runs a migration, it updates the schema.rb file using the database as a source. It doesn't look at the existing schema.rb file, it just uses information from the database and overwrites it.

It appears that the real issue is that running the same migration in two different environments (different combinations of Ruby, Rails, MySQL, operating systems) may yield different results when generating a schema.rb file.

The solution is to make sure everybody checking in code is using the same software versions, to whatever extent possible. And if it isn't possible (because this is a Windows vs. Linux vs. Mac difference and you don't feel like changing your OS) you'll just have to deal with the inconvenience.

Thanks for clarifying that for me. I'll have to see if I can hack together something that can circumvent changing the file if it didn't actually change! — wesdotcool, Feb 15 '13 at 19:55

score 2 · Answer 2 · answered Sep 01 '16 at 00:19

For me the solution was making a rake db:schema:load first. And than rake db:migrate stopped changing my schema.rb for no reason.

CAUTION: rake db:schema:load will delete ALL of your existing data and recreate the database in respect of existing schema.rb.

rails changes schema.rb for no reason

2 Answers2