Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for MSSQL unique constraint #4887

Merged
merged 5 commits into from Dec 13, 2021
Merged

Added support for MSSQL unique constraint #4887

merged 5 commits into from Dec 13, 2021

Conversation

mlevit
Copy link
Contributor

@mlevit mlevit commented Dec 12, 2021

MSSQL supports both unique indexes and unique constraints. One of the issues we found was unique index (current implementation) cannot be used with foreign key relationships. We must use unique constraints instead.

This is all based on issue #4825

I thought I'd give it a go and update the way MSSQL handles table.unique. This is my first PR here so please let me know if there's anything missing, which I'm sure there is.

I created a new test which seems to work fine 馃

@kibertoad
Copy link
Collaborator

Can you create a PR for https://github.com/knex/documentation with documentation?
Also TypeScript types need to be updated

Copy link
Collaborator

@OlivierCavadenti OlivierCavadenti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can push tests with add another one in mssql.js file (after "test adding unique key" test) and check the generated SQL.

@mlevit
Copy link
Contributor Author

mlevit commented Dec 12, 2021

@kibertoad could you point me in the right direction? I'm no TS developer, so not really sure what to look at.

@kibertoad
Copy link
Collaborator

@mlevit I think somewhere around here:

unique(columnNames: readonly (string | Raw)[], options?: Readonly<{indexName?: string, storageEngineIndexType?: string, deferrable?: deferrableType}>): TableBuilder;

@mlevit
Copy link
Contributor Author

mlevit commented Dec 12, 2021

@kibertoad @OlivierCavadenti are we happy with the argument name constraint? Is it descriptive enough or should we change it?

@kibertoad
Copy link
Collaborator

kibertoad commented Dec 12, 2021

@mlevit Something more explicitly boolean like isConstraint or useConstraint might be less surprising, but I defer to @OlivierCavadenti here.

@mlevit
Copy link
Contributor Author

mlevit commented Dec 13, 2021

My only issue is the argument is only usable for MSSQL... so not really sure what the best play here is. Would createMssqlConstraint be too verbose? isConstraint is good, but sort of doesn't make sense for other DBs.

@kibertoad
Copy link
Collaborator

@mlevit We don't do db-specific naming for db-specific parameters. Note in documentation is sufficient

@mlevit
Copy link
Contributor Author

mlevit commented Dec 13, 2021

Documentation updated knex/documentation#373

@OlivierCavadenti
Copy link
Collaborator

@kibertoad @OlivierCavadenti are we happy with the argument name constraint? Is it descriptive enough or should we change it?

useConstraint seems nice in my opinion, more descriptive.

@mlevit
Copy link
Contributor Author

mlevit commented Dec 13, 2021

useConstraint seems nice in my opinion, more descriptive.

Done.

@OlivierCavadenti OlivierCavadenti merged commit b612cdc into knex:master Dec 13, 2021
@OlivierCavadenti
Copy link
Collaborator

Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants