push-zvyqlvlovrwp - Branch - prisma/prisma-engines

fix(mysql): use column defs from `execute` and not `prepare`

#5565

Comparing

push-zvyqlvlovrwp

(

3621b27

) with

main

(

4c9c25c

)

Improvements: 0

Regressions: 0

Untouched: 11

New: 0

Dropped: 0

Ignored: 0

Benchmarks

Passed

small_read

query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::small_read

110.1 µs

109.9 µs

large_read

query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::large_read

1.6 ms

mutation

query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::mutation

6.5 ms

build (large)

query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::schema_builder::build (large)

5.3 ms

validate (medium)

query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::psl::validate (medium)

15.5 ms

validate (small)

query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::psl::validate (small)

2.3 ms

deep_read_query

query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::deep_read_query

1.9 ms

validate (large)

query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::psl::validate (large)

71.3 ms

71.4 ms

build (small)

query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::schema_builder::build (small)

305.1 µs

305.4 µs

medium_read

query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::medium_read

315.8 µs

316.7 µs

build (medium)

query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::schema_builder::build (medium)

-1%

2.6 ms

Commits

Click on a commit to change the comparison range

Base

main

4c9c25c

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

3621b27

2 days ago

by aqrln

Home Terms Privacy Docs