ym0506 commented on issue #33978: URL: https://github.com/apache/shardingsphere/issues/33978#issuecomment-4418318948
@strongduanmu I took a quick look at this issue and I think the failure is caused by SQL federation's Calcite type mapping for MySQL `BIGINT UNSIGNED`. For MySQL, `BIGINT UNSIGNED` is mapped to `BigInteger.class` in `MySQLDataTypeOption`. Then SQL federation builds the Calcite row type via `SQLFederationDataTypeBuilder#createJavaType(...)`. As a result, the column is exposed to Calcite as `JAVATYPE(java.math.BigInteger)`, while the numeric literal is inferred as SQL `BIGINT`. Calcite then rejects the comparison: `JAVATYPE(java.math.BigInteger) = BIGINT` This matches the reported exception. If this issue has not been resolved yet, I would like to work on a PR for it. My planned direction is: 1. Add regression coverage for MySQL `BIGINT UNSIGNED` equality with numeric literals. 2. Cover the join case between two `BIGINT UNSIGNED` columns if possible. 3. Adjust SQL federation's type mapping or coercion so unsigned bigint remains range-safe but is still comparable during Calcite validation. Please let me know if this direction sounds acceptable. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
