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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the implicit unique constraints on 1:1 relations explicit #10503

Closed
tomhoule opened this issue Nov 30, 2021 · 5 comments · Fixed by prisma/prisma-engines#2944
Closed

Make the implicit unique constraints on 1:1 relations explicit #10503

tomhoule opened this issue Nov 30, 2021 · 5 comments · Fixed by prisma/prisma-engines#2944
Assignees
Labels
kind/improvement An improvement to existing feature and code. team/client Issue for team Client. team/psl-wg team/schema Issue for team Schema. tech/engines/datamodel Issue about parsing/validation/rendering of the Prisma schema tech/engines/migration engine Issue in the Migration Engine topic: breaking change topic: indexes topic: prisma4 topic: relations topic: schema
Milestone

Comments

@tomhoule
Copy link
Contributor

tomhoule commented Nov 30, 2021

Problem

The following Prisma schema:

model A {
  id   Int @id
  b_id Int
  b    B @relation(fields: [b_id], references: [id])
}

model B {
  id Int @id
  as A?
}

doesn't contain an @unique, but if you migrate it, you will have a unique index on b_id so that it's enforced that the relation is really one-to-one and not one-to-many. If you introspect it, it would become explicit in the schema. This is a very old opinionation. Prisma as a whole has evolved towards more explicitness, less "magic" in the schema to better reflect the reality of the database.

This issue is here to propose that we enforce that the backing scalar fields of the relation are covered by a unique constraint, meaning we would validate (and possibly help with autoformatting or code actions) so that the valid schema would be:

model A {
  id   Int @id
  b_id Int @unique
  b    B   @relation(fields: [b_id], references: [id])
}

model B {
  id Int @id
  as A?
}

This works exactly the same if the relation is backed by multiple scalar fields.

Suggested solution

  1. Add a validation with a clear error message explaining that to enforce the one-to-one-ness of the relation, a unique constraint is required on such and such fields, with an example of how it would look like.
  2. Offer a code action to do this automatically in LSP-enabled editors.

This is a breaking change, because existing valid Prisma schemas would not pass validation anymore. It can only be released in a new major version.

Alternatives

  • Do nothing and keep the current behaviour.
  • Make explicating the unique constraint part of the reformatting logic

Additional context

@tomhoule tomhoule added process/candidate topic: schema tech/engines/migration engine Issue in the Migration Engine tech/engines/datamodel Issue about parsing/validation/rendering of the Prisma schema topic: relations team/schema Issue for team Schema. team/psl-wg topic: indexes labels Nov 30, 2021
@Jolg42 Jolg42 added this to the 3.7.0 milestone Dec 1, 2021
@Jolg42 Jolg42 modified the milestones: 3.7.0, 3.8.0 Dec 21, 2021
@pimeys pimeys self-assigned this Dec 30, 2021
@janpio janpio added the kind/improvement An improvement to existing feature and code. label Jan 3, 2022
@janpio janpio added team/client Issue for team Client. and removed Prisma4 labels Jan 11, 2022
@janpio
Copy link
Member

janpio commented Jan 11, 2022

Client team label as this will trigger work in fixing QE tests.

@janpio
Copy link
Member

janpio commented Jan 11, 2022

Note: This is not for implementation, but only consideration what to do about it next.

@BroNils
Copy link

BroNils commented Jun 16, 2022

any solution for this? i don't have much time to wait for prisma4 got released

@janpio
Copy link
Member

janpio commented Jun 16, 2022

This only adds a restriction, you can just enforce that manually already - if there a 1:1 relation, make sure there is a @unique constraint.

@BroNils
Copy link

BroNils commented Jun 16, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/improvement An improvement to existing feature and code. team/client Issue for team Client. team/psl-wg team/schema Issue for team Schema. tech/engines/datamodel Issue about parsing/validation/rendering of the Prisma schema tech/engines/migration engine Issue in the Migration Engine topic: breaking change topic: indexes topic: prisma4 topic: relations topic: schema
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants