chore(deps): bump @prisma/generator-helper from 7.1.0 to 7.4.1

[dependabot]

Bumps @prisma/generator-helper from 7.1.0 to 7.4.1.

Release notes

Sourced from @​prisma/generator-helper's releases.

7.4.1

Today, we are issuing a 7.4.1 patch release focused on bug fixes and quality improvements.

🛠 Fixes

Prisma Client

• Fix cursor-based pagination regression with parameterised values (prisma/prisma#29184)
• Preserve Prisma.skip through query extension argument cloning (prisma/prisma#29198)
• Enable batching of multiple queries inside interactive transactions (prisma/prisma#25571)
• Add missing JSON value deserialization for JSONB parameter fields (prisma/prisma#29182)
• Apply result extensions correctly for nested and fluent relations (prisma/prisma#29218)
• Allow missing config datasource URL and validate only when needed (prisma/prisma-engines#5777)

Driver Adapters

• @​prisma/adapter-ppg: Handle null values in type parsers for nullable columns (prisma/prisma#29192)

Prisma Schema Language

• Support where argument on field-level @unique for partial indexes (prisma/prisma-engines#5774)
• Add object expression and object member support to schema reformatter (prisma/prisma-engines#5776)

🙏 Huge thanks to our community

Many of the fixes in this release were contributed by our amazing community members. We're grateful for your continued support and contributions that help make Prisma better for everyone!

7.4.0

Today, we are excited to share the 7.4.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

Caching in Prisma Client

Today’s release is a big one, as we introduce a new caching layer into Prisma ORM. But why the need for a caching layer?

In Prisma 7, the query compiler runs as a WebAssembly module directly on the JavaScript main thread. While this simplified the architecture by eliminating the separate engine process, it introduced a trade-off: every query now synchronously blocks the event loop during compilation.

For individual queries, compilation takes between 0.1ms and 1ms, which is barely noticeable in isolation. But under high concurrency this overhead adds up and creates event loop contention that affects overall application throughput.

For instance, say we have a query that is run over and over, but is a similar shape:

// These two queries have the same shape:
const alice = await prisma.user.findUnique({ where: { email: 'alice@prisma.io' } })
const bob = await prisma.user.findUnique({ where: { email: 'bob@prisma.io' } })

Prior to v7.4.0, this would be reevaluated ever time the query is run. Now, Prisma Client will extract the user-provided values and replaces them with typed placeholders, producing a normalized query shape:

... (truncated)

Commits

• 6b8702c fix(client,internals,migrate,generator-helper): handle multibyte UTF-8 charac...
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)