Latest Results
fix(mysql): use column defs from `execute` and not `prepare`
When using prepared statements, MySQL returns information about the
columns and their types (at least) twice: once in prepare response
and once as part of execute response each time the statement is
executed.
The MySQL driver we use allows to read either of those freely. Our
implementation of MySQL connector in `quaint` chose to use the column
definitions from the prepared statement and not from the query response.
While it's not generally incorrect, it's not what most applications and
ORMs do, so a regression a Vitess that affected the columns returned by
the prepared statement for some queries wasn't caught until it started
affecting Prisma users in production. However, it does have legitimate
shortcomings:
- Sometimes the column definitions returned when executing the query
have richer and more complete type information (see [this comment][]
by a Vitess maintainer).
- In some cases columns cannot be known before executing the statement
in MySQL — specifically, when calling stored procedures (or when using
anonymous blocks in MariaDB). This was the root cause of [#6173][],
which was worked around by synthesizing the `f0`, `f1`, etc. column
names. That wasn't the right solution, however, as it is trivially
possible to get the correct column names from the execute response
(see the diff in the corresponding regression test which now has the
correct column name returned).
Unresolved questions:
1. Changing the behavior of raw queries with prepared statements will
technically be a breaking change as some people are relying on it.
It's not documented though. Should we treat it as a bugfix and merge
anyway before Prisma 7?
2. TypedSQL must retrieve column definitions from prepare by
construction. What's the current behavior and what types are
generated by `prisma generate --sql` when using stored procedures in
MySQL?
[this comment]: https://github.com/prisma/prisma/issues/27734#issuecomment-3117341080
[#6173]: https://github.com/prisma/prisma/issues/6173 Active Branches
#55650%
#55300%
#54780%
© 2025 CodSpeed Technology