[
https://issues.apache.org/jira/browse/CALCITE-6912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938358#comment-17938358
]
Chris Dennis commented on CALCITE-6912:
---------------------------------------
I'm not convinced this is confined to just reflective schema. This initial
reproduction is simply my initial attempt at producing a standalone sharable
version of what I'm seeing in-house when working with an adapter that exposes a
Java typed database schema through Calcite and Avatica. I'm happy to try to
work out a more convincing test case but I think something is up with the
handling of byte[] vs ByteString. In my actual failure I have an Enumerable
RelNode reporting a physical type of byte[] (along with associated generated
explicit casts) but then allowing a ByteString created by Avatica after a
setBytes call to propagate through to the generated code and cause a CCE at
query execution time.
> Confusion around typing of byte[] versus ByteString in Enumerable code
> ----------------------------------------------------------------------
>
> Key: CALCITE-6912
> URL: https://issues.apache.org/jira/browse/CALCITE-6912
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
> Affects Versions: 1.35.0, 1.40.0
> Reporter: Chris Dennis
> Priority: Major
> Labels: pull-request-available
>
> The Enumerable convention code generation seems to be at odds with both
> Avatica and at other times with itself when trying to handle {{byte[]}} field
> types. This leads to a variety of failure either at during code generation,
> or at query execution time. I will push an example of a failing query in PR
> shortly after filing this... but I suspect most any query that attempts to
> project a byte[] typed column has a good chance of tripping over itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
