Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Array[UInt16] forcibly converted to short[] #2078

Open
guosk123 opened this issue Jan 9, 2025 · 4 comments
Open

Array[UInt16] forcibly converted to short[] #2078

guosk123 opened this issue Jan 9, 2025 · 4 comments
Labels
bug data-type data type processing issues jdbc-v2 jdbc-v2 issues

Comments

@guosk123
Copy link

guosk123 commented Jan 9, 2025

Describe the bug

Steps to reproduce

  1. create table
clickhouse-server:24.3.12.75

CREATE TABLE IF NOT EXISTS test.t_flow_test
(
 `timestamp` DateTime64(3, 'UTC'),
`src_ip` Array(UInt16),
`dst_ip` UInt16
)
ENGINE = MergeTree
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (timestamp);
  1. use jdbc vcersion
<dependency>
    <groupId>com.clickhouse</groupId>
    <artifactId>clickhouse-jdbc</artifactId>
    <version>0.6.1</version>
</dependency>
  1. search in my code
insert into t_flow_test values (NOW(), [50001,50002], 51443);

select src_ip, dst_ip from t_flow_test limit 1;

result:
src_ip, dst_ip
[-15535, -15534], 51443

When I debug it, i found that UInt16 is converted to UnsignedShort in the code, but Array[UInt16] is converted to short[] in the code.

@guosk123 guosk123 added the bug label Jan 9, 2025
@chernser chernser added data-type data type processing issues jdbc-v2 jdbc-v2 issues labels Jan 9, 2025
@chernser
Copy link
Contributor

Good day, @guosk123!
Thank you for reporting!

@chernser
Copy link
Contributor

Good day, @guosk123!
This is inconsistency issue. We might not fix it in the old JDBC implementation because a new one is around the corner.
New JDBC implementation will use short because we moved away from custom numeric data type as they are not portable. In most cases JDK provided types will be used.

@guosk123
Copy link
Author

Good day, @guosk123! This is inconsistency issue. We might not fix it in the old JDBC implementation because a new one is around the corner. New JDBC implementation will use short because we moved away from custom numeric data type as they are not portable. In most cases JDK provided types will be used.

Okay, I got it

@mshustov
Copy link
Member

mshustov commented Jan 18, 2025

New JDBC implementation will use short because we moved away from custom numeric data type as they are not portable. In most cases JDK provided types will be used.

@chernser if it's the expected behaviour, should we close as won't fix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug data-type data type processing issues jdbc-v2 jdbc-v2 issues
Projects
None yet
Development

No branches or pull requests

3 participants