[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836560#comment-17836560
]
Ruben Q L edited comment on CALCITE-6265 at 4/15/24 3:10 PM:
-------------------------------------------------------------
I have [opened a PR|https://github.com/apache/calcite/pull/3758] to fix the
problems (partially reverting some of the original changes, partially making
some adjustments):
- It seems the original issue could be solved easier in RexToLixTranslator, by
simply converting to Number and then to storageType in case of Numeric types.
- All the bind* tests that were added on the first PR still work; plus a new
test that I added to illustrate the issues that I found (with setBigDecimal)
- The problems that I detected on my downstream project are also fixed.
- The only thing that is missing (didn't have the time to dig deeper) from the
original solution is the "check for overflow and throw". I have left the
auxiliary method that generates this dynamic code (Expressions#convertChecked),
and left a TODO on EnumUtils#convert for future work. I think that this was not
part of the strict scope of the current ticket's description, so IMHO it would
be acceptable open a separate ticket and work on that in the future, adding
more thorough tests on this regard (and not just the one
JdbcTest#bindOverflowingTinyIntParameter that was originally added, which I
disabled on my branch). UPDATE: created CALCITE-6366 for this purpose.
I'd appreciate some feedback, and if you think I can move on and merge my
proposal.
was (Author: rubenql):
I have [opened a PR|https://github.com/apache/calcite/pull/3758] to fix the
problems (partially reverting some of the original changes, partially making
some adjustments):
- It seems the original issue could be solved easier in RexToLixTranslator, by
simply converting to Number and then to storageType in case of Numeric types.
- All the bind* tests that were added on the first PR still work; plus a new
test that I added to illustrate the issues that I found (with setBigDecimal)
- The problems that I detected on my downstream project are also fixed.
- The only thing that is missing (didn't have the time to dig deeper) from the
original solution is the "check for overflow and throw". I have left the
auxiliary method that generates this dynamic code (Expressions#convertChecked),
and left a TODO on EnumUtils#convert for future work. I think that this was not
part of the strict scope of the current ticket's description, so IMHO it would
be acceptable open a separate ticket and work on that in the future, adding
more thorough tests on this regard (and not just the one
JdbcTest#bindOverflowingTinyIntParameter that was originally added, which I
disabled on my branch).
I'd appreciate some feedback, and if you think I can move on and merge my
proposal.
> Type coercion is failing for numeric values in prepared statements
> ------------------------------------------------------------------
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Tim Nieradzik
> Assignee: Ruben Q L
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
> placeholder in a prepared statement, a {{ClassCastException}} is thrown.
> h2. Test case
> {{final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
> CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> h2. Stack trace
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.<init>(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
