Though I have not felt the pain, I have been a long time user of structure 
files in legacy environments and think consistent names are a good idea. On the 
flip side, the same could be said for constraint name “churn” too. I have seen 
this in big Oracle teams and unavoidable to my knowledge and/or only fixed with 
a custom script after the rake migration task. 

All that said, I think this is something Rails could solve and the PG limit 
does seem like a big constraint too.

 - Cheers,
   Ken

On January 13, 2015 at 11:12:47 AM, ch...@sinjakli.co.uk (ch...@sinjakli.co.uk) 
wrote:

I'm really glad to see foreign key support has made its way into Rails 
migrations, but very quickly ran into an issue with it when working in teams 
using structure.sql.

Previously, we'd been using the foreigner gem, which generated FK names based 
on the table and column. This meant the name was consistent every time you ran 
the migration. With the version that made it into 4.2, part of the FK name is 
random. This means every dev who runs the migration locally generates a 
different version of structure.sql, leading to conflicts in version control.

Right now we're working round this by explicitly setting the FK name in our 
migrations. I'd like to find a way of fixing this in Rails itself though.

My understanding was the reason for switching away from the old format was that 
the name is arbitrary, and can fall out of date on column renames. By itself 
I'm not totally convinced that's enough reason to get rid of the more 
descriptive names (though I agree it's debatable). The restriction on the 
length of the name (63 characters in Postgres, for example) is a more 
compelling reason for me.

Either way, I'd like to contribute a patch to make migrations generate 
consistent FK names. I'm happy to implement either of the following (or 
something else if anyone's got a better ideas):

* Switch back to generating human-readable names, accept that people with long 
table/column names will occasionally have to set them manually
* Generate that human-readable name, hash it, and append a substring of the 
hash to "fk_rails_". This would give you a name which is both short and 
consistent.

Would really appreciate feedback on those approaches.

Cheers,
Chris
--
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 rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

-- 
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 rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Reply via email to