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 simple CRC hash of the input data equally solve the issue of names potentially getting out of date, without introducing non-determinancy?
More way-too-late bikeshedding: IMHO the method in 4.2 should be renamed to add_foreign_key_with_constraint. A foreign key is just the key for an association. A foreign key constraint is a different concept to a foreign key.
IMHO it’s really important that users understand the difference, and only add constraints when they want them.
The thing is, if you live your life on recent versions of PostgreSQL, they work well enough to be usable. But on MySQL particularly - and in PostgreSQL before they implemented the special weakened lock types - they cause a lot of unintended side effects because they result in a standard shared lock being taken on the parent row.
On one of my big apps we put FKCs in in ~2008, and we’re now actually going through dropping FKCs when we get the chance, because they just cause too many problems at runtime.
Basically, if table A is a parent to table B, and you have an FKC linking the two, then an update to a B row will take some kind of shared lock on A. But it’s also common to have a form for A records which nests B records, and then in practice the #update action is going to save A, and then save the Bs… and then you get deadlocks.
I’ve been finding this sort of problem (there’s others) comes up so often that I’ve gone right off the idea of foreign key constraints, and now tell ppl to only add them when they specifically need them. (And I find usually it’s relatively rare that you do in practice because a lot of parent tables don’t get deletes, and those that do you tend to want to seralize things using update locks anyway.)
TL;DR I would like people to learn from our mistakes and not to accidentally get foreign key constraints when they think they are just adding a foreign key :).