Latest Results
chore: update Rust to 1.97.1 (#5849)
## Overview
Bumps the pinned toolchain in `rust-toolchain.toml` from 1.92.0 to
1.97.1 and fixes everything the new Clippy complains about, so `make
pedantic` is green again.
## Changes
The bulk of the diff is the new lint against redundant references in
formatting macro arguments. `format!`, `panic!` and `assert_eq!` already
take their arguments by reference, so the explicit `&` was pointless.
Purely mechanical, no behaviour change.
The rest, one by one:
- **`sql_schema_differ.rs`** — `Some(TableChange::…).filter(|_|
differ.primary_key_changed())` becomes
`differ.primary_key_changed().then_some(TableChange::…)`. The lint warns
that this reorders the condition against the value; harmless here, since
the value is a unit variant and the predicate is a pure query.
- **`native_types.rs`, `flavour/postgres.rs`** — `a.and_then(|a|
b.map(|b| (a, b)))` becomes `a.zip(b)`.
- **`datasource_loader.rs`** — `sort_by(|(a, _), (b, _)| a.cmp(b))`
becomes `sort_by_key`.
- **`validations/fields.rs`** — the `DecimalType` capability check moves
from an `if` inside the match arm into a match guard.
- **`quaint/src/ast/values.rs`, `query_document/selection.rs`** — two
blocks that returned `None` on the miss now use `?`.
- **`configuration.rs`, `statistics.rs`, `differ_database.rs`** —
`iter().map(|(_, v)| …)` over maps becomes `values()`.
- **`visitor/mssql.rs`** — drop a no-op `into_iter()` on an argument
that already accepts `IntoIterator`.
## Inlined format arguments
Since the redundant-reference fix was already rewriting those formatting
macro calls, the second commit captures their arguments in the format
string as well — `panic!("Unknown driver adapter: {}", s)` becomes
`panic!("Unknown driver adapter: {s}")`.
This is scoped to the lines this PR already touches. Every argument that
*can* be captured is, including in calls that also carry arguments that
cannot be, so a few strings mix the two styles:
```rust
format!("{alter_column_prefix} SET DATA TYPE {}", render_column_type(columns.next, renderer))
```
What stays positional is only what the language cannot capture: method
calls (`field.name()`) and field accesses (`self.schema`).
Note that `clippy::uninlined_format_args` only fires when *all* of a
call's arguments are capturable, so the mixed cases above are beyond
what the lint would ask for. With this PR applied, no fully-capturable
call remains on any line it touches.
## Verification
- `make pedantic` passes (both the native and the
`wasm32-unknown-unknown` Clippy passes).
- `make test-unit` passes: 112 test binaries, no failures.
---------
Signed-off-by: Alexey Orlenko's AI Agent <robot@aqrln.net> fix(qc): don't wrap single-statement plans in a transaction (#5840)
Fixes prisma/prisma#29748. Supersedes prisma/prisma#29759, following
[the feedback
there](https://github.com/prisma/prisma/pull/29759#issuecomment-5050033598)
that this belongs in `Expression::simplify` rather than in the query
interpreter.
## Problem
The query graphs for `updateMany` and `createMany` report
`needs_transaction() == true`, so their plans get wrapped in a
`Transaction` expression even though they translate to exactly one SQL
statement. A single statement is atomic on its own, so the wrapper only
adds `BEGIN`/`COMMIT` round-trips — and it makes both operations fail
hard on driver adapters without transaction support (e.g.
`PrismaNeonHttp`), while the structurally identical `deleteMany`
executes its single `DELETE` directly:
```
Error: Transactions are not supported in HTTP mode
at PrismaNeonHttpAdapter.startTransaction
```
## Solution
- `Expression::simplify` now unwraps `Transaction(expr)` when `expr`
contains at most one statement node (`Query`/`Execute`). The new
`max_statement_count` helper computes an upper bound over the expression
tree, taking the maximum over mutually exclusive `If` branches and
treating nested `Transaction` expressions as unbounded.
- `translate()` wraps the root in `Transaction` *before* the simplify
pass (previously after), so the new simplification can see the wrapper.
Plans with two or more statements keep the transaction exactly as
before.
Note on chunking: a single chunkable statement (e.g. a large
`createMany` exceeding the bind-parameter limit) may still be split into
multiple queries by the client at runtime, and those chunks now run
without a transaction. This matches how chunked `deleteMany` and read
queries — which are never wrapped in a transaction — behave today; a
comment in `simplify` documents this.
## Tests
- Added an `update-many` case to the query translation snapshot tests
(there was none).
- Updated `create-many` and `create-many-and-return` snapshots: the
`transaction` wrapper around their single statement is gone;
multi-statement snapshots (nested writes, m2m, etc.) are unchanged.
- Verified end-to-end by building the query compiler Wasm from this
branch, linking it into `prisma/prisma` (unmodified `main`), and running
a generated client against a driver adapter whose `startTransaction`
rejects: `createMany`/`updateMany` now succeed, and explicit
`$transaction([...])` still fails with the adapter's error as
documented.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Oleksii Orlenko <alex@aqrln.net> Latest Branches
0%
0%
fix/postgres-aggregate-and-array-casts 0%
fix/partial-index-raw-arity © 2026 CodSpeed Technology