-
-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scheme .references() and foreignKey() 's constraint naming strategies are not unified. #537
Comments
Just ran into the same issue. It seems impossible to delete a constraint created with Also, the code in |
EDIT: |
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 |
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 (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 |
Describe the bug
Ref to Discord discussion Link
.field("star_id", .uuid, .required, .references("stars", "id"))
will create a constraint with name suffixed with_fkey
in postgresql database.it is different from the constraint created with
foreignKey()
which prefixed withfk
.The behavior is not working as expected as the docment says
the are the same
if we create a constraint with
.references()
and want to modify the constraint in the next migration, we will find it's hard to delete constraint with.deleteConstraint()
method.Expected behavior
.references()
andforeignKey()
should have the same naming strategy.Environment
The text was updated successfully, but these errors were encountered: