[
https://issues.apache.org/jira/browse/ARROW-18300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631810#comment-17631810
]
James Henderson edited comment on ARROW-18300 at 11/10/22 5:42 PM:
-------------------------------------------------------------------
Thanks - yep, no worries, of course.
FWIW we can't return accurate parameter types at the point of creating a
prepared statement - partly because XT is a dynamic database, but also partly
because we're not sure it's possible in the general case:
* For us, we can't accurately type the params in {{INSERT INTO users (id, name)
VALUES (?, ?)}} because a user is allowed to put any value in those columns -
aware we might be the exception to the rule on this one. We currently say that
the param Schema has two columns, both of which are 0-leg dense unions, and
then refine it when the user binds some parameters, but I'm not sure how viable
that workaround might be long-term.
* More generally, even in statically typed databases, (admittedly quite
contrived) queries like {{SELECT ? FROM foo}} have untypable params - Postgres,
for example, throws an error if you try to get the parameter metadata through
JDBC for this one.
was (Author: jarohen):
Thanks - yep, no worries, of course.
FWIW we can't return accurate parameter types at the point of creating a
prepared statement - partly because XT is a dynamic database, but also partly
because we're not sure it's possible in the general case:
* For us, we can't accurately type the params in {{INSERT INTO users (id, name)
VALUES (?, ?)}} because a user is allowed to put any value in those columns -
aware we might be the exception to the rule on this one. We currently say that
the param Schema has two columns, both of which are 0-leg dense unions, and
then refine it when the user binds some parameters, but I'm not sure how viable
that workaround might be long-term.
* More generally, even in statically typed databases, (admitted quite
contrived) queries like {{SELECT ? FROM foo}} have untypable params - Postgres,
for example, throws an error if you try to get the parameter metadata through
JDBC for this one.
> [Java][FlightRPC] FlightSQL error: 'Parameter ordinal out of range' executing
> a prepared stmt with params
> ---------------------------------------------------------------------------------------------------------
>
> Key: ARROW-18300
> URL: https://issues.apache.org/jira/browse/ARROW-18300
> Project: Apache Arrow
> Issue Type: Bug
> Components: FlightRPC, Java
> Affects Versions: 10.0.0
> Reporter: James Henderson
> Assignee: David Li
> Priority: Major
>
> Hey again :)
> I'm getting a 'parameter ordinal 1 out of range' error trying to set a
> parameter on the returned AvaticaPreparedStatement. Repro:
> * Open a FlightSQL JDBC connection
> * {{conn.prepareStatement}} with a SQL query containing params (e.g. {{INSERT
> INTO users (id, name) VALUES (?, ?)}})
> * `ps.setString(1, "foo")` -> above error, thrown from
> {{AvaticaPreparedStatement.getParameter(int)}}
> I had a bit of a dig to try to identify a potential cause:
> * the {{Meta.Signature}} passed to the {{AvaticaPreparedStatement}} on
> creation has an empty parameter list - this is what causes the out-of-bounds
> error.
> * in {{ArrowFlightMetaImpl.prepare}}, it calls {{newSignature}}, but this
> only takes the SQL query, and so {{newSignature}} creates the signature with
> the empty list. The call to {{ArrowFlightSqlClientHandler.prepare}} happens
> on the line after - could we pass the param Schema from this result to
> {{newSignature}}?
> Let me know if I can help narrow this down further or help with the fix :)
> James
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
