For context: I am the original author of the fix-db-schema-conflicts 
<> gem.

It prevents the kind of annoying churn described in this earlier thread:!searchin/rubyonrails-core/sort$20columns$20schema|sort:date/rubyonrails-core/h6q8nGFzGKs/pztvg5sJrbgJ

Namely, when two people make changes to the same Rails codebase it can 
create a situation where they are forever locked into a contest of 
flip-flopping the order of columns/foreign-keys, etc in the `db/schema.rb` 
file each time they make changes.

The fix-db-schema-conflicts gem "fixes" this by prepending some code to the 
Rails schema generation that sorts everything before spitting it out to 

Additionally it uses Rubocop to autoformat the generated file to use 
uniform spacing and column alignment.

Over the years I've maintained this gem the vast majority of issues 
surrounding it have come from Rubocop compatibility with Rails. The Rubocop 
autocorrect is really something that could be applied separately by any 
team and was only added to my gem as a convenience, which has turned into a 
huge mess in terms of gem maintenance. The real value of my gem comes from 
the ordering of the database schema.

I propose making a small change to Rails that integrates my gem's schema 
sorting logic 
into Rails by default, with a configuration option to preserve the ordering 
if a specific application relies on column sort order for some reason.

This change would not affect structure.sql in any way.

In my mind this is a *common source of frustration for every single Rails 
project that has more than contributor*, and it is a *simple, low-risk 
change (can be reverted with a configuration).*

I would be very glad to do the work if it was desired.

What does the community think, before I spend time on a PR for this?

You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit

Reply via email to