terrymanu commented on issue #27459:
URL:
https://github.com/apache/shardingsphere/issues/27459#issuecomment-3637968316
## Issue Understanding
- Env: ShardingSphere-Proxy 5.3.2. Running select count(distinct
column_name) from table_name. Expected type is BIGINT, but sometimes it
inherits the column type (e.g., VARCHAR(63)), and for datetime columns it
sometimes returns NULL. count() without distinct returns
BIGINT as expected.
## Root Cause
- Not enough information to confirm. Likely the Proxy’s distributed
aggregation metadata isn’t forcing count(distinct …) to BIGINT, so the result
type can follow the source column type; the datetime NULL may come from the
same aggregation/type-conversion path. But we
need more details (backend DB type/version, schema, routing) to be sure.
## Analysis
- With a single backend DB, the database would normally return BIGINT.
Type drift usually appears when Proxy does in-memory aggregation and doesn’t
override the result metadata.
- The datetime NULL case might be a real aggregation result or a
conversion bug; more context is required to tell.
- We need more context to distinguish a framework bug from a
configuration-specific behavior.
## Conclusion / Info Needed
To proceed, please share:
1. Backend database type and version (e.g., MySQL/PostgreSQL/Oracle).
2. Table schema (especially the column types) and sample data that trigger
the issue.
3. Actual returned value and column type (e.g., via JDBC
ResultSetMetaData), showing the BIGINT/VARCHAR/NULL cases.
4. Whether the table is sharded/broadcast/single, and how many shards are
routed (enable props.sql-show: true and share the routing log).
5. Whether SQL Federation or other special configs are enabled.
With these details, we can analyze further and provide a fix or
workaround.
--
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]
