v0.12.3 Breaks queries with clauses that refer to a relations' fields
I updated the generator to get the #681 fix, but it seems to have broken this specific set of filters for the query.
I narrowed the issue down to this part:
db.Post.Root.Where(db.Post.Slug.Equals(slug)),
Because posts are a tree structure, posts that aren't first: true contain a reference to their root post, so the query looks for either posts where first: true and the slug matches or posts where first: false and the slug of the post's root post matches.
Even if this is the only clause, nothing is returned on github.com/prisma/prisma-client-go v0.12.3-0.20211111111520-460d1d78ffcb but I get expected results on github.com/prisma/prisma-client-go v0.11.1-0.20211014160141-a4310b37583e
There's a db.Post.Root.Fetch() so I'd expect this to work, seems like a bug.
Here's a diff between the two graphql queries it generated where a is version 0.12.3 (broken) and b is version 0.11.1 (working)
❯ diff a b
4c4,12
< root: { is: { slug: { equals: "ckw1pdbsw05024us748xzi7f8-center" } } }
---
> AND: [
> {
> root: {
> is: {
> AND: [{ slug: { equals: "ckw1pdbsw05024us748xzi7f8-center" } }]
> }
> }
> }
> ]
8c16
< orderBy: [{ createdAt: "asc" }]
---
> orderBy: { createdAt: "asc" }
(See the full graphql queries here)
Broken Version: v0.12.3-0.20211111111520-460d1d78ffcb
query {
result: findManyPost(
where: {
root: { is: { slug: { equals: "ckw1pdbsw05024us748xzi7f8-center" } } }
}
take: 50
skip: 0
orderBy: [{ createdAt: "asc" }]
) {
id
title
slug
body
short
first
pinned
createdAt
updatedAt
deletedAt
userId
rootPostId
replyPostId
categoryId
author {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
category {
id
name
description
colour
sort
admin
}
tags {
id
name
}
replyTo {
id
title
slug
body
short
first
pinned
createdAt
updatedAt
deletedAt
userId
rootPostId
replyPostId
categoryId
author {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
}
reacts {
id
emoji
createdAt
postId
userId
user {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
}
root {
id
title
slug
body
short
first
pinned
createdAt
updatedAt
deletedAt
userId
rootPostId
replyPostId
categoryId
author {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
}
}
}
Working version: v0.11.1-0.20211014160141-a4310b37583e
query {
result: findManyPost(
where: {
AND: [
{
root: {
is: {
AND: [{ slug: { equals: "ckw1pdbsw05024us748xzi7f8-center" } }]
}
}
}
]
}
take: 50
skip: 0
orderBy: { createdAt: "asc" }
) {
id
title
slug
body
short
first
pinned
createdAt
updatedAt
deletedAt
userId
rootPostId
replyPostId
categoryId
author {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
category {
id
name
description
colour
sort
admin
}
tags {
id
name
}
replyTo {
id
title
slug
body
short
first
pinned
createdAt
updatedAt
deletedAt
userId
rootPostId
replyPostId
categoryId
author {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
}
reacts {
id
emoji
createdAt
postId
userId
user {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
}
root {
id
title
slug
body
short
first
pinned
createdAt
updatedAt
deletedAt
userId
rootPostId
replyPostId
categoryId
author {
id
email
authMethod
name
bio
admin
createdAt
updatedAt
deletedAt
}
}
}
}
Using this minimal query (none of the other filters in the code I linked above).
q := d.db.Post.
FindMany(db.Post.Root.Where(db.Post.Slug.Equals(slug))).
With(
db.Post.Author.Fetch(),
db.Post.Category.Fetch(),
db.Post.Tags.Fetch(),
db.Post.ReplyTo.Fetch().With(
db.Post.Author.Fetch(),
),
db.Post.Reacts.Fetch().With(
db.React.User.Fetch(),
),
db.Post.Root.Fetch().With(
db.Post.Author.Fetch(),
),
).
Take(max).
Skip(skip).
OrderBy(db.Post.CreatedAt.Order(db.ASC))
Hopefully this helps narrow the source!
Thanks for the detailed report, especiall the gql diff, and thanks for your patience, looking into it
By chance, do you know if this is still an issue? 😅
I'm not sure, that codebase still uses Prisma though and it seems to be running quite well with fairly high traffic still. However, the "posts" schema referenced has since been moved to a separate project called Storyden which uses a different codegen tool for the database so I don't have any reference unfortunately.
Probably worth closing for now and if the issue appears again, this issue may be useful as a reference!