Repository navigation
fix: fix test after a patch bb0dd494862c ("sql: fix work of bind variables") - #105
Conversation
1700345 to
dfd29d8
Compare
| $stmt = $this->client->prepare('INSERT INTO prepare_execute VALUES(:id, :name)'); | ||
|
|
||
| $insertResult1 = $stmt->executeUpdate(1, 'foo'); | ||
| $insertResult2 = $stmt->executeUpdate([':id' => 1], [':name' => 'foo']); |
There was a problem hiding this comment.
Do I understand correctly that, previously, it was possible to pass positional parameters to a query with named placeholders like
INSERT INTO foo VALUES(:id, :name)
as long as their order matched the placeholders, but with this change, that no longer works?
The test now fails because id is bound to NULL:
Failed to execute SQL statement: NOT NULL constraint failed: prepare_execute.id
But what happens if someone tries to update a nullable column and passes its value positionally instead of by name? For example:
UPDATE invoices SET discount_amount = :discount_amount WHERE id IN (
SELECT id FROM invoices WHERE discount_amount IS NOT NULL
)
If the client passes the value positionally rather than by the name discount_amount, will existing discount amounts be silently set to NULL? Based on the error above, it looks like it. If so, is this intended behavior, or is it a regression?
There was a problem hiding this comment.
Yes, it will be set to NULL.
According to the new rules, queries with named variables require an array containing those named variables (for example, if a query uses :id, you must provide an array like {{[":id"] = 1}}). The positional approach is supported only for anonymous variables (?) and positional variables (e.g., $1); for instance, using ? or $1 in a query will work with an array like {1}.
The change was not unintentional.
dfd29d8 to
026db10
Compare
026db10 to
376b9e5
Compare
e202858 to
118cbfe
Compare
118cbfe to
fc19c7d
Compare
|
Note: This PR intentionally contains only the minimal changes needed for compatibility with #13565. Tests for the proposed behavior described in RFC #13620 will be added separately, once the RFC is agreed upon. |
No description provided.