My own preference is towards the longer, descriptive names. Partly for consistency with index naming, and partly because it's nice to be able to glance at them and know what they are (though I understand the argument for them falling out of date).
I'll go ahead and make a PR for that option. If there's serious objections to it, hashing is easy enough to add. Thanks for sharing your thoughts on this! Cheers, Chris On Tuesday, January 13, 2015 at 9:19:37 PM UTC, James Coleman wrote: > > As far as the Postgres limit, that also applies to index names. So I don't > see why we need to handle it any different for foreign keys (i.e., with > indexes it just means that it fails on creation if the auto-generated one > is too long and the dev has to provide a manual name.) > > On Tue, Jan 13, 2015 at 4:15 PM, Amiel Martin <am...@carnesmedia.com > <javascript:>> wrote: > >> My vote would be to be consistent with the way index names work; the long >> human readable version. >> >> -Amiel >> >> On Tue, Jan 13, 2015 at 12:31 PM, Ken Collins <k...@actionmoniker.com >> <javascript:>> wrote: >> >>> 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 <javascript:> ( >>> ch...@sinjakli.co.uk <javascript:>) 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 >>> <https://github.com/senny/rails/commit/8768305f20d12c40241396092a63e0d56269fefe#diff-a0775e1ec64264dc76a8ee71a5211ae3R697>. >>> >>> 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-co...@googlegroups.com <javascript:>. >>> To post to this group, send email to rubyonra...@googlegroups.com >>> <javascript:>. >>> 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-co...@googlegroups.com <javascript:>. >>> To post to this group, send email to rubyonra...@googlegroups.com >>> <javascript:>. >>> 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-co...@googlegroups.com <javascript:>. >> To post to this group, send email to rubyonra...@googlegroups.com >> <javascript:>. >> 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.
