upgraded to Rails 4.2.6: rake db:migrate inserting column limits into schema.rb

Question

I'm finding that a lot of our columns, which have no limit: xxx in the migrations are suddenly getting limits applied to the columns, not in the database itself, but in our db/schema.rb file. This isn't terrible when we're just doing a migration in any environment. The place it becomes troublesome is when we setup fresh databases--they no longer match what we have in our various prod/staging/qa environments.

I need to find a way to have this not happen.

As things stand any time we add a migration we end up having to do an extremely complex and tedious git add -p db/schema.rb and as time goes on I'm losing confidence that our db/schema.rb file matches up with any version of reality.

As a data point, if I run rake db:migrate with no new migrations, db/schema.rb gets rebuilt and has an insanely huge diff.

Answer 1

According to this note in Rails 4.2 Release Notes:

The PostgreSQL and SQLite adapters no longer add a default limit of 255 characters on string columns.

And this comment to the relevant Rails Pull Request 14579:

The db/schema.rb is used to exactly recreate your database. All your string columns were added before 4.2 with an implicit limit of 255. At that time it was not necessary to dump the limit to db/schema.rb because it was the default. Now that we've changed the default to no limit. We must dump these limits to recreate the database.

the issue is not a new default but a reflection of the old one.

To resolve the issue I'd suggest running a migration which would drop the limits from the relevant fields and then recreating schema.rb from the database. This should result in a new consistent state.