[
https://issues.apache.org/jira/browse/CALCITE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18037544#comment-18037544
]
Tomoyuki Morita commented on CALCITE-7206:
------------------------------------------
I encounter the same problem when EnumerableMergeJoin is generated with join
condition contains `object1 = object2`.
[PhysTypeImpl.generateComparator|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/adapter/enumerable/PhysTypeImpl.java#L426]
generate duplicate `compare(Object, Object)` method because it always [add
bridge compare
method|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/adapter/enumerable/PhysTypeImpl.java#L494]
with signature `compare(Object, Object)`.
Bridge method should be eliminated if the javaRowClass is Object.
> duplicate 'compare' method in JoinType.INNER, for Enumerable code generator
> ---------------------------------------------------------------------------
>
> Key: CALCITE-7206
> URL: https://issues.apache.org/jira/browse/CALCITE-7206
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.40.0
> Reporter: Jerome Isaac Haltom
> Priority: Minor
>
> I'm building my own adapter. Right now I have only implemented a TableScan so
> my adapter isn't doing much of anything to get in the way. Upon running an
> inner join:
> SELECT * FROM trailmates1.\"User\" AS u INNER JOIN trailmates1.UserProfile as
> up ON u.Id = up.UserId
> I receive the following exception:
>
> {code:java}
> java.sql.SQLException: Error while executing SQL "SELECT * FROM
> trailmates1."User" AS u INNER JOIN trailmates1.UserProfile as up ON u.Id =
> up.UserId": Error while compiling generated Java code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> return
> org.apache.calcite.linq4j.EnumerableDefaults.mergeJoin(org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("trailmates1"), java.lang.Object[].class,
> "User").asEnumerable().orderBy(new
> org.apache.calcite.linq4j.function.Function1() {
> public Object apply(Object[] v) {
> return v[0];
> }
> public Object apply(Object v) {
> return apply(
> (Object[]) v);
> }
> }
> , org.apache.calcite.linq4j.function.Functions.nullsComparator(false,
> false)), org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("trailmates1"), java.lang.Object[].class,
> "UserProfile").asEnumerable().orderBy(new
> org.apache.calcite.linq4j.function.Function1() {
> public Object apply(Object[] v) {
> return v[1];
> }
> public Object apply(Object v) {
> return apply(
> (Object[]) v);
> }
> }
> , org.apache.calcite.linq4j.function.Functions.nullsComparator(false,
> false)), new org.apache.calcite.linq4j.function.Function1() {
> public Object apply(Object[] left) {
> return left[0];
> }
> public Object apply(Object left) {
> return apply(
> (Object[]) left);
> }
> }
> , new org.apache.calcite.linq4j.function.Function1() {
> public Object apply(Object[] right) {
> return right[1];
> }
> public Object apply(Object right) {
> return apply(
> (Object[]) right);
> }
> }
> , null, new org.apache.calcite.linq4j.function.Function2() {
> public Object[] apply(Object[] left, Object[] right) {
> return new Object[] {
> left[0],
> left[1],
> left[2],
> left[3],
> right[0],
> right[1],
> right[2],
> right[3],
> right[4],
> right[5],
> right[6],
> right[7],
> right[8]};
> }
> public Object[] apply(Object left, Object right) {
> return apply(
> (Object[]) left,
> (Object[]) right);
> }
> }
> , org.apache.calcite.linq4j.JoinType.INNER, new java.util.Comparator(){
> public int compare(Object v0, Object v1) {
> final int c;
> c = org.apache.calcite.runtime.Utilities.compare((Comparable) v0,
> (Comparable) v1);
> if (c != 0) {
> return c;
> }
> return 0;
> } public int compare(Object o0, Object o1) {
> return this.compare(o0, o1);
> } }, null);
> }
> public Class getElementType() {
> return java.lang.Object[].class;
> }
> {code}
> The problem is the last Function argument, which has compare(Object v0,
> Object V1) as well as compare(Object o0, Object o1).
> My guess is this has SOMETHING to do with the types of the columns in the
> schema. I'll take a look at that and clarify. These IDs are UUIDs, and I
> might have messed something up so they are object types. However, those
> should still technically not generate bad code.......
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
