[
https://issues.apache.org/jira/browse/CALCITE-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17980143#comment-17980143
]
Julian Hyde commented on CALCITE-7038:
--------------------------------------
[~christian.beikov], By 'external data' I presume you mean data in the form of
Java heap objects.
Don't imagine that because Enumerable convention works on Java heap objects it
can work on *any* Java heap objects. Enumerable has been successful because it
has constraints. For example, a value of the {{DATE}} SQL type will be
represented as an {{int}} or {{java.lang.Integer}}.
If you want a convention that works on arbitrary Java objects (presumably with
some kind of mapping) go ahead and create one. "Xxx does not work as I expect"
is not a bug, or a license to go change Xxx. It might be a sign that you need
to create a Yyy.
> EnumerableUncollect unnecessarily assuming fields are Comparable
> ----------------------------------------------------------------
>
> Key: CALCITE-7038
> URL: https://issues.apache.org/jira/browse/CALCITE-7038
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.39.0
> Reporter: Christian Beikov
> Priority: Major
>
> {{EnumerableUncollect}} uses {{JavaRowFormat.LIST}} which unnecessarily
> requires that all the field values are {{Comparable}} leading to a
> {{ClassCastException}} when executing a query like e.g. against data that is
> not fully comparable
> {code:sql}
> select r.id
> from GitHubRepository r
> where not exists (
> select 1
> from unnest(r.branchProtectionRules) as br
> and exists (select 1 from GitHubRepository r)
> )
> {code}
> Assuming {{branchProtectionRules}} is {{Array(Struct(matchingRefs:
> Integer))}}. Note that the {{EXISTS}} predicate in the unnest subquery is
> needed to trigger the failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
