Skip to content

Conversation

@strongduanmu
Copy link
Member

@strongduanmu strongduanmu commented Feb 2, 2025

@strongduanmu strongduanmu changed the title [CALCITE-1466] Support for UNSIGNED types of int,long,float etc. in type system [CALCITE-1466] Support for UNSIGNED types of TINYINT, SMALLINT, MEDIUMINT, INT BIGINT in type system Feb 2, 2025
@strongduanmu strongduanmu changed the title [CALCITE-1466] Support for UNSIGNED types of TINYINT, SMALLINT, MEDIUMINT, INT BIGINT in type system [CALCITE-1466] Support for UNSIGNED types of TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT in type system Feb 2, 2025
Copy link
Contributor

@mihaibudiu mihaibudiu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look fine, but it's hard to tell whether all code paths that may be relevant have been handled until we have some end-to-end tests.

@strongduanmu
Copy link
Member Author

The changes look fine, but it's hard to tell whether all code paths that may be relevant have been handled until we have some end-to-end tests.

Yes, I agree with you, end-to-end testing is very important. Currently, I have tested different unsigned types with calcite avatica 1.26.0-SNAPSHOT and they all work fine. When this PR is merged, I will try to support unsigned types in calcite and add more end-to-end test cases.

@mihaibudiu
Copy link
Contributor

I am wondering whether it will pay off to actually build a set of classes UnsignedInt, UnsignedShort, etc, which would encapsulate these abstractions in a clean way. I am not sure that this is the right place for them - BTW. But I think you will need them eventually in the runtime of Calcite to properly implement the semantics of unsigned arithmetic.

@mihaibudiu
Copy link
Contributor

I notice that Guava has some of these.

@strongduanmu
Copy link
Member Author

@mihaibudiu Thank you for your remind, I will try to implement this feature using a class like Guava UnsignedInt.

@strongduanmu
Copy link
Member Author

Hi @mihaibudiu, I spent some time looking at Guava. Currently, it only provides UnsignedInteger and UnsignedLong. Other UnsignedByte and UnsignedShort are not provided by Guava.

In addition, I found that MySQL provides another idea, we can handle them by mapping a wider range of Java types. For example, the BIGINT type is usually mapped to java.lang.Long for processing, while BIGINT UNSIGNED needs to be mapped to java.math.BigInteger for processing. For more type mappings, please refer to the document: https://dev.mysql.com/doc/connector-j/en/connector-j-reference-type-conversions.html

Through this mapping conversion method, we do not need to add any classes, and the Calcite runtime can handle UNSIGNED types. What do you think of this approach? I will keep trying if you have any suggestions.

Copy link
Contributor

@ILuffZhe ILuffZhe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good.

@mihaibudiu
Copy link
Contributor

From my experience, in the long term it pays off to implement the right abstractions.
I expect there will be a lot of work to be done using unsigned types, including in the type checker, expression simplification, and runtime system. In particular, at runtime the enumerable implementation looks at the runtime types to make some decisions (maybe that's a bug in the implementation). So if the runtime will see a Long it won't know whether it's a real Long or an UnsignedInt in disguise.

@strongduanmu
Copy link
Member Author

From my experience, in the long term it pays off to implement the right abstractions. I expect there will be a lot of work to be done using unsigned types, including in the type checker, expression simplification, and runtime system. In particular, at runtime the enumerable implementation looks at the runtime types to make some decisions (maybe that's a bug in the implementation). So if the runtime will see a Long it won't know whether it's a real Long or an UnsignedInt in disguise.

Hi @mihaibudiu, thank you for sharing these valuable experiences. These are issues I had not considered before. Since I am still a novice, I will spend some time to understand type checking, expression simplification, etc., and then try to add new UnsignedInt, UnsignedLong and other types.

@F21 F21 force-pushed the main branch 8 times, most recently from c7cee40 to a9dc6f8 Compare February 23, 2025 22:29
@mihaibudiu
Copy link
Contributor

Can we merge this PR?
Frankly, we won't know whether this stuff works until there are some end-to-end tests, so it would be nice to have a confirmation that Calcite will be able to use this.

@strongduanmu
Copy link
Member Author

Can we merge this PR? Frankly, we won't know whether this stuff works until there are some end-to-end tests, so it would be nice to have a confirmation that Calcite will be able to use this.

Hi @mihaibudiu, according to your review suggestion, we'd better introduce unsigned type to facilitate Calcite to do some boundary checking on types. This part of work is not included in the current PR. I suggest merging this PR first, and then I will introduce https://github.com/jOOQ/jOOU in the next PR to support unsigned type. What do you think?

@mihaibudiu
Copy link
Contributor

I don't know if Avatica needs to take a dependency on joou.
Can you write some tests in Calcite that confirm that this PR works as expected?
Such tests can be merged after this PR is merged; you will have to run them by linking Calcite with an unreleased version of Avatica.

@strongduanmu
Copy link
Member Author

I don't know if Avatica needs to take a dependency on joou. Can you write some tests in Calcite that confirm that this PR works as expected? Such tests can be merged after this PR is merged; you will have to run them by linking Calcite with an unreleased version of Avatica.

Good suggestion, I will add tests in calcite.

@strongduanmu strongduanmu force-pushed the dev-CALCITE-1466 branch 2 times, most recently from cdc32af to ebaed66 Compare June 1, 2025 01:45
@mihaibudiu
Copy link
Contributor

There is now apache/calcite#4411; I guess the tests should use both PRs.

@strongduanmu
Copy link
Member Author

There is now apache/calcite#4411; I guess the tests should use both PRs.

Yes, I will test in calcite when #4411 is merged.

@mihaibudiu
Copy link
Contributor

I have resolved the issue in Jira, perhaps you should open a new one specifically mentioning Avatica.

@strongduanmu strongduanmu changed the title [CALCITE-1466] Support for UNSIGNED types of TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT in type system [CALCITE-5094] Calcite JDBC Adapter and Avatica should support MySQL UNSIGNED types of TINYINT, SMALLINT, INT, BIGINT Jun 19, 2025

@Override
public UShort getUShort() throws SQLException {
return UShort.valueOf(String.valueOf(getLong()));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems a bit convoluted

Copy link
Member Author

@strongduanmu strongduanmu Aug 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because the UShort.valueOf method does not support long type parameters.

Types.TINYINT, "TINYINT", ColumnMetaData.Rep.BYTE), true, true),
MetaImpl.columnMetaData("shortField", 2, ColumnMetaData.scalar(
Types.SMALLINT, "SMALLINT", ColumnMetaData.Rep.SHORT), true, true),
MetaImpl.columnMetaData("intField", 3, ColumnMetaData.scalar(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this we don't have, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, while I was adding tests for unsigned types, I noticed that signed types were also lacking tests, so I added those tests.

@mihaibudiu
Copy link
Contributor

Please rebase and squash the commits.

…UNSIGNED types of TINYINT, SMALLINT, INT, BIGINT
@mihaibudiu mihaibudiu merged commit 9e6f954 into apache:main Aug 26, 2025
12 of 13 checks passed
@strongduanmu strongduanmu deleted the dev-CALCITE-1466 branch August 26, 2025 04:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants