PRAHLAD09-dev commented on PR #39217: URL: https://github.com/apache/shardingsphere/pull/39217#issuecomment-5067602973
Thanks for the review. I revisited the implementation based on your feedback and traced how SQLFederationResultSet#getObject() actually obtains its value. getObject() eventually goes through getValue(), which applies DialectSQLFederationColumnTypeConverter#convertColumnValue(). So getColumnClassName() should describe the Java type after that dialect-specific conversion, rather than relying only on the JDBC type returned by getColumnType(). I updated the implementation accordingly: Added a dialect hook for reporting the Java class produced by column value conversion. For MySQL, BOOLEAN values are converted to Integer, so getColumnClassName() now reports java.lang.Integer for that case. Kept the BigInteger case based on Calcite's original JavaType, since mapping it through JDBC BIGINT would incorrectly report Long even though the actual value remains a BigInteger. For types without a special runtime conversion, the existing JDBC type-to-Java-class mapping remains the fallback. I also added regression coverage for the BigInteger case, dialect-converted class behavior, the JDBC type mappings, and MySQL BOOLEAN -> Integer. I verified the changes with the SQL federation core and MySQL tests, including the reactor build, and they pass successfully. Updated in commit 4c05f420. -- 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]
