Scheme .references() and foreignKey() 's constraint naming strategies are not unified. about fluent-kit HOT 4 OPEN

Just ran into the same issue. It seems impossible to delete a constraint created with .references(...) w/o resorting to its name (whose naming strategy seems to be left to Postgres - or at least I wasn't able to find the corresponding code).

Also, the code in constraintIdentifier uses the altered schema as prefix for all (foreign) fields (see here). If the target (foreign) table name would be used, the generated name would actually be correct it would make much more sense.

from fluent-kit.

Btw. in Postgres, the foreign key does not have a _fkey suffix for me. Instead it begins with fk: (much like the generated constraintIdentifier). However, the issue really is the incorrect table prefix for foreign fields as I just described.

EDIT:
Scratch that. Seems like the constraints I was seeing were from an older (pre Vapor 4) installation. Newly generated databases actually have the _fkey suffix as described by the OP. Which explains why I couldn't find any code generating that name. The _fkey suffix is created by postgres, as explained here.

from fluent-kit.

We're aware of this but I think that changing it would be considered a breaking change so will need to wait for Fluent 5

from fluent-kit.

I had intended to fix this by, as @ffried correctly suggests, using the foreign table name instead of the referencing table name, as this was technically never correct to begin with. Unfortunately, even if doing so wouldn't be breaking due to the sudden naming change (which it is), it would still require either a semver-major break or a massive amount of very painful refactoring and code duplication, thanks to design flaws in FluentKit (very short version: as things are now, there's no means of making the foreign table's name available in several of the places a constraint identifier needs to be computed).

I should also mention that while Postgres does semantically treat the column-constraint and table-constraint forms of a foreign key constraint more or less identically, neither MySQL not SQLite can say the same (MySQL silently ignores the column form, and SQLite applies different default semantics depending on which is used); ANSI SQL considers them to be distinct (though related) constructs, which means it's technically incorrect to expect them to be interchangeable.

While this is unfortunately not documented anywhere, the consequence of the above is that the .deleteConstraint() modifier should only be used for table constraints. To drop (or add!) a column constraint, use .fieldUpdate() instead. I will add this to the documentation (hopefully in a comprehensible fashion! 😅) when I get a chance.

(I'll also note that much of the oddity involved here has to do with the radically different SQL syntaxes for table alteration between Postgres and MySQL and the lack of any properly structured support inside Fluent for handling it. This in turn is mostly thanks to ALTER TABLE support having been tacked on well after the 4.0.0 release and too many things having been indiscriminately marked public...)

from fluent-kit.