Prisma Interview Questions — Medium

• Looping for (const post of posts) post.author issues one query per iteration - the client does NOT auto-batch lazy access.
• Fix: single findMany({ include: { author: true } }) producing two total queries (posts + IN-list of authors).
• Detection: Prisma client query logging (log:["query"]) exposes the storm instantly.

---

prisma.user.update({
  where: { id }, data: { posts: { create: {...}, deleteMany: { published: false } } }
})

• Nested create/update/deleteMany run INSIDE one implicit transaction - atomicity free without $transaction wrapper.
• Limits: cross-model ordering logic beyond nesting still needs interactive transactions.

---

• relationLoadStrategy: "join" (Postgres) emits LEFT JOINs fetching relations in ONE round trip vs classic two-query batch.
• Choose join for latency-sensitive paths with wide networks; batch (default) often cheaper for huge child sets (row multiplication on joins).
• Per-query choice - benchmark both directions on representative data.

---

• No @Version primitive natively; pattern: filter update by expected value:

prisma.doc.updateMany({ where: { id, version }, data: { content, version: { increment: 1 } } })

• count===0 ⇒ concurrent modification → retry/merge UX.
• updateMany bypasses unique checks returning count - deliberate semantics worth knowing.

---

• Defaults maxWait 2s / timeout 5s - long logic inside throws P2028.
• Design: keep txns SHORT (pure DB mutations), move IO/computation outside, pass ids across boundaries; raise limits only deliberately with lock-spread awareness.
• Interactive txns hold a connection - nested pool starvation under concurrency is the hidden cost.

---