-
Notifications
You must be signed in to change notification settings - Fork 26
[Preview 14] Migrate error - ambiguous self relation detected #290
Comments
@pantharshit00 Please triage this and if this is a bug, apply the candidate label to it 🙏 |
I can confirm this bug. Strangely enough Also, adding the directive also throws an error: Reproduction: https://github.com/harshit-test-org/prisma-prisma2-752 |
@nhuesmann: model Game {
id String @id @default(cuid())
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
title String
handle String
description String
expansions Game[] @relation("Expansion")
expands Game[] @relation("Expansion")
relatedGames Game[] @relation("RelatedGames")
relatedGamesBack Game[] @relation("RelatedGames")
} |
what does it mean |
NOTE: I accidentally tapped "close and comment" rather than "comment" as I'm writing this on my phone. Ignore those GitHub status updates please. @mavilein Interesting... Say I have a Game with id 1. If I add Games with ids 2, 3, and 4 to Game 1's
If I'm wrong, and functionality I mentioned I needed is still present, please let me know. Either way, I'd recommend making that clearer in the docs if possible. As I said I've seen other devs in other issues express the expectation that they'd be able to have a single field that references the model it's a part of, so I don't think I'm alone in the confusion. @divyenduz @pantharshit00 feel free to hop in if you have a good answer to this question as well. |
@nhuesmann : Your observation is correct that we introduced a behavioral change at some point. But i am fairly certain that we introduced this change already with Prisma 1. So i am a bit confused that you are saying that even some Prisma 2 previews had the old behavior.
Before the change this kind of relation was a special thing and behaved differently from all other relations in our system. What i would recommend here is to explicitly handle this usecase in your application layer. If you want this behavior you should select the fields |
@mavilein Thanks for your reply. Regarding when this change occurred, I can't say exactly when it was, however I will say that I'm running I understand the reasoning behind changing it. Have to admit I'm a little bummed about it, but I get that you can't satisfy every user desire and every use case, and that you're optimizing for performance. Thanks again for the clarification and recommendations, I appreciate it. |
@mavilein I just thought of another question / potential issue with this approach. Say I have a
Based on your last recommendation, the Let's assume I have some UI that lets a Please let me know if this makes sense, and if you understand why I fear this may actually end up being a problem. I don't want to have to write my own subpar implementations of awesome Prisma features like |
@nhuesmann : Your concerns are right about this one. This still does not warrant the introduction of such a feature in my opinion since it occurs a performance cost for every relation. Example schema model User {
id Int @id
friendships Friendship[]
...
}
model Friendship {
id Int @id
user1 User
user2 User
} Example Photon call: (This is best effort code. Maybe this does not work exactly like that. Should convery the idea though) const friendships: Friendship[] = await photon.friendships.findMany({
where: {
OR: [
{ user1: { id: 'abc' }},
{ user2: { id: 'abc' }},
]
},
}); |
This approach makes the prisma2 CLI crash (#976). |
@mavilein I just ran into this issue while trying to implement a model User {
id Int @id @default(autoincrement())
friendships Friendship[]
...
}
enum FriendshipStatus {
PENDING
ACCEPTED
DECLINED
BLOCKED
}
model Friendship {
id Int @id @default(autoincrement())
status FriendshipStatus @default(PENDING)
user1 User
user2 User
lastActionUser User
} Schema parsing fails with the following message:
It doesn't make sense to differentiate I can even do without having the I'd love to hear your/anyone else from Prisma team's thoughts, thanks! |
@divyenduz @mavilein I just wanted to follow up after a few weeks to see if this was going to be in any upcoming sprints. This is an important feature for me, as I need to model a friendship and currently can't (unless I figure out some undesirable workarounds, but they'd ultimately be subpar solutions). |
@divyenduz @mavilein Hi guys, just following up again after a few more weeks to see if there are any plans to fix this bug. I have a feature that depends heavily on this functionality. Thanks! |
@nhuesmann : There are no plans to change this behavior. My suggestion was more pseudo a spontaneous idea and i just realized that it won't work like that. The following schema should work: model User {
id Int @id
friendships1 Friendship[] @relation("Friendship1")
friendships2 Friendship[] @relation("Friendship2")
}
model Friendship {
id Int @id
user1 User @relation("Friendship1")
user2 User @relation("Friendship2")
} This schema should enable the query i sketched in an earlier comment. |
@mavilein Thanks for the reply. I'll admit I'm a little bummed about having to set up these arbitrary back relation fields, but I understand there's a perf reason behind Prisma's decision to do this. I'll just hope that down the road there might be a slightly cleaner solve for this, but in the mean time I think this will take care of what I need. Thanks again. |
Related to prisma/prisma#488 and prisma/prisma#671
Prisma2 version:
prisma2@2.0.0-preview014, binary version: 188a379c9b8c6650e5812f9bdb7407d7b197692f
Schema:
Notes:
When I try to perform
prisma2 lift up
I get "ambiguous self relation detected" due to therelatedGames
field. If I try to add the@relation
directive, I get an error when I try to performprisma lift save
in which the schema can't be validated bcNamed relations require an opposite field
. In my model, theexpansions
/expands
fields are different, because a Game can either haveexpansions
, or it itself can be an expansion for several other games (meaning it will have several Games in itsexpands
field). TherelatedGames
field doesn't have any concept of different roles in a relationship likeexpansions
andexpands
, it's simply a way to model that games can be "related" to each other, i.e. for similar game recommendations. What should I do to resolve this?The text was updated successfully, but these errors were encountered: