From 5288f1446080d4379bbd217d13f7742fdb39dd98 Mon Sep 17 00:00:00 2001 From: Nikolas Date: Fri, 3 May 2024 17:03:27 +0200 Subject: [PATCH 1/2] Update 100-query-optimization-performance.mdx --- .../100-queries/100-query-optimization-performance.mdx | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx b/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx index 6c5c39a7b5..3cf993ffcd 100644 --- a/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx +++ b/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx @@ -36,7 +36,10 @@ The n+1 problem occurs when you loop through the results of a query and perform -The Prisma Client dataloader automatically **batches** `findUnique()` queries that ✔ occur in the same tick and ✔ have the same `where` and `include` parameters. +The Prisma Client dataloader automatically _batches_ `findUnique()` queries that occur in the same [tick](https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick#processnexttick) and have the same `where` and `include` parameters if: + +- All criteria of the `where` filter are on scalar fields (unique or non-unique) of the same model you're querying +- All criteria must use the `equal` filter, whether that's via the shorthand or explicit syntax `(where: { field: , field1: { equals: } })` Automatic batching of `findUnique()` is particularly useful in a **GraphQL context**. GraphQL runs a separate resolver function for every field, which can make it difficult to optimize a nested query. From 2337738a7843149ae8e24843680870ddea6fb003 Mon Sep 17 00:00:00 2001 From: Nikolas Date: Fri, 3 May 2024 17:14:03 +0200 Subject: [PATCH 2/2] Update content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx --- .../100-queries/100-query-optimization-performance.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx b/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx index 3cf993ffcd..965f49571c 100644 --- a/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx +++ b/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx @@ -38,8 +38,9 @@ The n+1 problem occurs when you loop through the results of a query and perform The Prisma Client dataloader automatically _batches_ `findUnique()` queries that occur in the same [tick](https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick#processnexttick) and have the same `where` and `include` parameters if: -- All criteria of the `where` filter are on scalar fields (unique or non-unique) of the same model you're querying -- All criteria must use the `equal` filter, whether that's via the shorthand or explicit syntax `(where: { field: , field1: { equals: } })` +- All criteria of the `where` filter are on scalar fields (unique or non-unique) of the same model you're querying. +- All criteria use the `equal` filter, whether that's via the shorthand or explicit syntax `(where: { field: , field1: { equals: } })`. +- No boolean operators or relation filters are present. Automatic batching of `findUnique()` is particularly useful in a **GraphQL context**. GraphQL runs a separate resolver function for every field, which can make it difficult to optimize a nested query.