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.
