[
https://issues.apache.org/jira/browse/CALCITE-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16818765#comment-16818765
]
Lai Zhou edited comment on CALCITE-2992 at 4/16/19 8:24 AM:
------------------------------------------------------------
[~julianhyde], you're right. I add a test case:
[https://github.com/apache/calcite/blob/c3d3c6468a54d0033073fc94d221c401c30be0a3/core/src/test/java/org/apache/calcite/test/enumerable/EnumerableJoinTest.java#L83]
The hashJoinKeysCompareIntAndLong() test method can pass through.
In my useCase, I customized the `EQUALS` operator with another
SqlOperandTypeChecker ,which perform a dynamic operand checking by a Hive
GenericUDFOPEqual. So the CAST translation is never taken.
But Calcite doesn't support implicit conversions well for types that belong to
different type family now.
See the test method hashJoinKeysCompareIntAndString(), it would fail.
I made a new commit to roll-back the last commit , and do something to enhance
the implicit conversions when
generating hash join keys. Considering follow case:
If leftKey type is String ,and rightKey type is Int, we can convert the keys
to Double.
If leftKey type is String ,and rightKey is Decimal, we can convert the keys to
Decimal.
The implicit conversions in this patch for hash join keys would’t depend on the
CAST translation , nor be in conflict with it .
was (Author: hhlai1990):
[~julianhyde], you're right. I add a test case:
[链接标题|[https://github.com/apache/calcite/blob/c3d3c6468a54d0033073fc94d221c401c30be0a3/core/src/test/java/org/apache/calcite/test/enumerable/EnumerableJoinTest.java#L83]]
The hashJoinKeysCompareIntAndLong() test method can pass through.
In my useCase, I customized the `EQUALS` operator with another
SqlOperandTypeChecker ,which perform a dynamic operand checking by a Hive
GenericUDFOPEqual. So the CAST translation is never taken.
But Calcite doesn't support implicit conversions well for types that belong to
different type family now.
See the test method hashJoinKeysCompareIntAndString(), it would fail.
I made a new commit to roll-back the last commit , and do something to enhance
the implicit conversions when
generating hash join keys. Considering follow case:
If leftKey type is String ,and rightKey type is Int, we can convert the keys
to Double.
If leftKey type is String ,and rightKey is Decimal, we can convert the keys to
Decimal.
The implicit conversions in this patch for hash join keys would’t depend on the
CAST translation , nor be in conflict with it .
> Make implicit conversions when generating hash join keys for an equiCondition
> -----------------------------------------------------------------------------
>
> Key: CALCITE-2992
> URL: https://issues.apache.org/jira/browse/CALCITE-2992
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.19.0
> Reporter: Lai Zhou
> Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Considering follow sql join:
>
> {code:java}
> select t1.*,t2.* from t1 join t2 on t1.intValue=t2.longValue
> {code}
> as known in java :
>
> {code:java}
> Integer intValue = 2;
> Long longValue = 2L;
> new Object[]{intValue}.hashCode().equals
> (
> new Object[]{longValue}.hashCode()
> )
> = false;
> {code}
> We shoudn't use the orginal Object as a key in the HashMap,
> I think it'd be better to convert hash join keys to string and compare string
> values.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
