[Rails-core] Rails 4.2 Foreign Key Naming

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

Re: [Rails-core] Rails 4.2 Foreign Key Naming

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/o

Re: [Rails-core] Rails 4.2 Foreign Key Naming

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 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 ar

Re: [Rails-core] Rails 4.2 Foreign Key Naming

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 a

Re: [Rails-core] Rails 4.2 Foreign Key Naming

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

Re: [Rails-core] Rails 4.2 Foreign Key Naming

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 c

Re: [Rails-core] Rails 4.2 Foreign Key Naming

Hi Yves, No worries. Glad to get another view. Given that the information is close by anyway (in the constraint as you point out), perhaps it's not worth the downside of the name falling out of date. On the flipside it may be worth thinking about variation between databases. I've not used MyS

Re: [Rails-core] Rails 4.2 Foreign Key Naming

On Thursday, January 15, 2015 at 12:42:31 PM UTC, Yves Senn wrote: > 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 val

Re: [Rails-core] Rails 4.2 Foreign Key Naming

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

Re: [Rails-core] Rails 4.2 Foreign Key Naming

Yes, they are shown in constraint error messages, but so are the metadata (table name and referenced column name). Following are example messages: MySQL: --- ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`activerecord_unittest`.`fk_test_has_fk`, C

Re: [Rails-core] Rails 4.2 Foreign Key Naming

It's a delicate decision, because if you do automatic human readable generation like in indexes then the expectation that renames should propagate is strong. Maybe it would be also nice for the purposes of the discussion here to explain the actual gotchas we've faced doing that for indexes, so the

Re: [Rails-core] Rails 4.2 Foreign Key Naming

True - good point. Using random values is a bit weird though, since two people running the same migration will get different names, and then their schemas will never quite match. This means dev machines’ schemas will differ from staging/test environments and them from production. Wouldn’t a s

Re: [Rails-core] Rails 4.2 Foreign Key Naming

I think changing the semantics of `add_foreign_key` is best saved for another discussion. The naming change seems to be contentious enough by itself. ;) A quick summary of the tradeoffs for human readable names: + Consistency with index naming + When they show up in query plans, they'll be unders

Re: [Rails-core] Rails 4.2 Foreign Key Naming

I'm not convinced that we need human readable foreign key names right now. Since 4.2. is out with this issue, for the time being I'd like to focus on a backportable solution. A pull request with deterministic names but still non-human readable is very welcome. This should be a fairly controlled

Re: [Rails-core] Rails 4.2 Foreign Key Naming

Sounds good. Glad to have a decision on this so we can get away from random names. I'm happy to do the work and get a PR in. Should hopefully have some time in the next week. Cheers, Chris On 30 January 2015 at 10:48, Yves Senn wrote: > I'm not convinced that we need human readable foreign key

Re: [Rails-core] Rails 4.2 Foreign Key Naming

For reference, that PR is now open . On Sunday, February 1, 2015 at 2:29:39 PM UTC, Chris Sinjakli wrote: > > Sounds good. Glad to have a decision on this so we can get away from > random names. > > I'm happy to do the work and get a PR in. Should hopef