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> 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> > 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 ( >> 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 >> <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-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. >> > > -- > 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.
