fix(mysql): use column defs from execute and not prepare
#5565
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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]: prisma/prisma#27734 (comment) [#6173]: prisma/prisma#6173
CodSpeed Performance ReportMerging #5565 will not alter performanceComparing Summary
|
WASM Query Engine File Size
WASM Query Compiler File Size
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
quaintchose 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 in 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:
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?
TypedSQL must retrieve column definitions from prepare by construction. What's the current behavior and what types are generated by
prisma generate --sqlwhen using stored procedures in MySQL?