chore(bigquery-jdbc): refactor PreparedStatement and CallableStatement - #13849
Conversation
…d Calendar date setters
… CallableStatement
…yParameterMetaData
# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
…ryJdbcSqlFeatureNotSupportedException
…nsive copying across statement interfaces
…d-java into ps-part2-metadata
… in BigQueryTypeCoercionUtility
… and update CallableStatement and ResultSet to delegate to BigQueryTypeCoercionUtility
…rom BigQueryParameterHandler
…rom BigQueryParameterHandler and delegate directly to BigQueryTypeCoercionUtility
# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
…rameterHandlerTest to FieldValueTypeBigQueryCoercionUtilityTest
…r in BigQueryTypeCoercionUtility
There was a problem hiding this comment.
Code Review
This pull request refactors parameter handling in BigQueryCallableStatement and BigQueryPreparedStatement by standardizing parameter names, adding checkClosed() validation, and introducing helper methods like getRawParameter. Feedback on these changes highlights a few inconsistencies: BigQueryCallableStatement.setDate uses convertDateToCalendar instead of convertDateWithCalendar, the overloaded getObject methods are missing checkClosed() checks, and temporal types are handled inconsistently between BigQueryPreparedStatement (bound as strings) and BigQueryCallableStatement (bound as raw temporal objects).
| return null; | ||
| } | ||
| if (sqlType == StandardSQLTypeName.INT64 | ||
| && (parameterValue instanceof Short |
There was a problem hiding this comment.
Why short/byte are special cased here?
There was a problem hiding this comment.
They are converted to Long because BigQuery represents all integers as 64-bit (INT64), and the underlying SDK class QueryParameterValue rejects INT64 parameters if passed as Short, Byte, or BigInteger instead of Long or Integer.
| || parameterValue instanceof BigInteger)) { | ||
| return ((Number) parameterValue).longValue(); | ||
| } | ||
| if (sqlType == StandardSQLTypeName.FLOAT64 && parameterValue instanceof Float) { |
There was a problem hiding this comment.
else-if was avoided because each preceding if block executes an early return, making else-if redundant and keeping the control flow clean and unnested.
| public <T> T getObject(String parameterName, Class<T> type) throws SQLException { | ||
| checkClosed(); | ||
| return coerceValueToType( | ||
| getParameterAndTrackNull(parameterName), type, "'" + parameterName + "'"); |
There was a problem hiding this comment.
Why quotes? I assume it is used in logger? if so, logger should add quotes
There was a problem hiding this comment.
The single quotes are not for a logger, but are used to format the user-facing BigQueryJdbcException message when type coercion fails, distinguishing parameter names (e.g., 'paramName') from numeric parameter indices (e.g., 1).
| public void registerOutParameter(int paramIndex, int sqlType) throws SQLException { | ||
| LOG.finer("registerOutParameter: paramIndex %s, sqlType %s", paramIndex, sqlType); | ||
| public void registerOutParameter(int parameterIndex, int sqlType) throws SQLException { | ||
| LOG.finer("registerOutParameter: parameterIndex %s, sqlType %s", parameterIndex, sqlType); |
wasNull(): Routed all parameter getter paths inBigQueryCallableStatementthrough centralizedgetRawParameterhelpers, ensuring consistentwasNull()state tracking across all fast-path and fallback reads.checkClosed()checks to all implemented methods inBigQueryCallableStatementandBigQueryPreparedStatement.LOG.finerentry logging.getRef,getSQLXML) to directly throwBigQueryJdbcSqlFeatureNotSupportedException.