Requires @@ for [partyId, partyName] even when [partyId] is already unique

[sahnishant]

My model party has a field Id which is the index and primary key and unique.
So automatically [Id, Name] will be unique.

This part of the code works fine in another model named Invoce. (Which is generated for each party.

party party @relation(fields: [partyId], references: [id]) partyId Int

But I am trying to make a relation

party party @relation(fields: [partyId, partyName], references: [id, name]) partyId Int partyName String @db.VarChar(255)

it shows the error as following

Error parsing attribute "@relation": The argument references must refer to a unique criterion in the related model. Consider adding an @@unique([id, name]) attribute to the model party.

Forcing to make unique the pair [id, name] makes no sense to me!

Am i missing something very fundamental?

[nurul3101]

Hello @sahnishant 👋

When you are defining a relation, and you specify the fields and references arguments in the @relation attribute, it expects the referenced fields to be a unique criterion in the related model.

In your initial example:

party party @relation(fields: [partyId], references: [id])
partyId Int

It's working because id is a unique field in the related model (most likely the primary key).

In your second example:

party party @relation(fields: [partyId, partyName], references: [id, name])
partyId Int
partyName String @db.VarChar(255)

You are trying to establish a relation using both the id and name fields. For this to work, the combination [id, name] must be unique in the related model party. It's a requirement from our end at the moment.

In your case, I can see why creating a unique index on a combination of [id, name] wouldn't help. I'll check this with the team to check how we can improve the UX for this case. Can you let me know your use case for adding name to the relation attribute? Was maintaining the relation with only the id field, which is unique, causing any issues?

[sahnishant]

The question is only academic now (to my practical purpose)

Its like if everyone in a country has a unique id, then the combination of [id, name] is by default unique for every individual becasue name itself is unique.

No there is no issue with using only the id.
At that stage I felt this could be a simpler way to handle my sql query. But I changed it later according to the model.

[janpio]

Can you actually create a foreign key in a (relational) database that refers to a unique and a non unique column?

If that does indeed work, you are correct that Prisma is enforcing a higher standard here that might not be necessary. You could open a feature request for that then (which would potentially lead us to investigate why we have this limitation right now one day).

[ludralph]

Hi there,

To keep our discussions organized and focused on the most relevant topics, we’re reviewing and tidying up our backlog. As part of this process, we’re closing discussions that haven’t had any recent activity and appear to be outdated.

If this discussion is still important to you or unresolved, we’d love to hear from you! Feel free to reopen it or start a new one with updated details.

For more details about our priorities and vision for the future of Prisma ORM, check out our latest blog post: https://www.prisma.io/blog/prisma-orm-manifesto.

Thank you for your understanding and being part of the community!