They may not be shown in query plans, but they are shown in constraint error messages, and the possibility of hitting those errors is the whole reason one adds foreign key constraints. It’s helpful to have an indication which kind of constraint was invalidated without having to look through the schema.
We do already tolerate the index names being irrelevant if they become inconsistent, but in my personal experience that doesn’t happen very often at all, since I’ve found indexed columns tend to be important and keep their names. So I would vote for meaningful names too. Just my 2c. > On 16/01/2015, at 01:42 , Yves Senn <yves.s...@gmail.com> wrote: > > Hey Chris > > Sorry for my late response. > > tl;dr: I'd rather not go for consistency with index naming but for a > consistent hash approach. > > We have descriptive names for indexes because they are shown to the user in > query plans. > This is not the case with foreign keys. When inspecting a database you can > look at the > constraint metadata. I don't see much value in encoding that metadata into > the name. > > In my opinion the drawbacks in the implementation are more sever. We faced a > lot of issues > when automatically renaming indexes. There are still cases where they fall > out of sync > with the actual metadata. Having descriptive names, which no longer represent > the metadata > is way worse in my opinion. > Also constant renaming when renaming tables and columns is not very > practical. The added > issue of the limited size makes this even worse. > > My gut feeling is in favor of constant non-descriptive names. I do remember > that I implemented > that exact behavior but we pivoted to purely random names. I'd like to go > through our archived > discussions regarding that change to make sure we have all the needed > information. > I haven't had the time to do so. > > Cheers, > -- Yves > > On Thursday, January 15, 2015 at 1:25:18 PM UTC+1, ch...@sinjakli.co.uk wrote: > 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 <>> > 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-co...@googlegroups.com <>. >> To post to this group, send email to rubyonra...@googlegroups.com <>. >> Visit this group at http://groups.google.com/group/rubyonrails-core >> <http://groups.google.com/group/rubyonrails-core>. >> For more options, visit https://groups.google.com/d/optout >> <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 <>. > To post to this group, send email to rubyonra...@googlegroups.com <>. > Visit this group at http://groups.google.com/group/rubyonrails-core > <http://groups.google.com/group/rubyonrails-core>. > For more options, visit https://groups.google.com/d/optout > <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 <>. > To post to this group, send email to rubyonra...@googlegroups.com <>. > Visit this group at http://groups.google.com/group/rubyonrails-core > <http://groups.google.com/group/rubyonrails-core>. > For more options, visit https://groups.google.com/d/optout > <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 > <mailto:rubyonrails-core+unsubscr...@googlegroups.com>. > To post to this group, send email to rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > Visit this group at http://groups.google.com/group/rubyonrails-core > <http://groups.google.com/group/rubyonrails-core>. > For more options, visit https://groups.google.com/d/optout > <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.
