Closed sshark closed 3 years ago
These seem to be Spring-specific issues as Spring expands named parameters (:foo
) that are collection-typed into individual placeholders. The driver generally doesn't accept Collection
parameters to be bound. What should ?groups
represent? Generally, SQL Server supports only named parameters prefixed with @
(such as @P0
).
Since this ticket isn't actionable here, closing it. Please create an issue for bind parameter reuse in Spring Framework.
My bad. This should be reported in MySQL R2DBC instead of MSSQL. Should I report in Spring Framework or r2dbc-mysql
? Thanks
Thanks for the detail. MySQL is different from the other databases as it uses anonymous bind markers only (?). These can be bound by index only and it is not possible to bind the same value to a bind marker that is used multiple times.
By using the bind marker multiple times I mean:
... WHERE foo IN (@p0, @p1) OR bar IN (@p0, @p1)
And we call Statement.bind("@p0", ...).bind("@p1", ...)
to pass on parameters to the driver.
Anonymous bind markers are bound by their ordinal position which requires something like Statement.bind(0, ...).bind(1, ...).bind(2, ...).bind(3, ...)
as it is not possible to refer within the SQL statement to the same parameter.
I think it would be possible to work around this limitation to some extent but it requires a lot of changes in the binding algorithm and it would only work for scalar types, not for ByteBuffer or Blob/Clob types as those can be consumed only once.
That being said, I recommend rewriting your query into a form where you pass in parameters multiple times.
Bug Report
I found similar issues with IN clause errors that were resolved but I could not get my queries to work correctly,
Versions
Current Behavior
I used the setup,
spring-boot-starter:2.4.5
,spring-data-r2dbc:1.2.8
, and JDK 11.0.11, to demonstrate.Queries (1) & (2A), using
?
, and (2), using:
, threw,I presume
?
does not support JavaCollection
in general and require a conversionQuery (3) threw,
Queries (4) and (5) threw,
However, these queries were fine,
Table schema
Expected behavior/code
I expect the queries with repeated parameters to behave the same as queries (6) and (7) or suggest alternative query notations