feat: support PreparedStatement#getParameterMetaData()#1218
Conversation
Add actual support for `PreparedStatement#getParameterMetaData()`. The first time this method is called for a PreparedStatement, the connection will now send the query to Cloud Spanner in analyze mode and without any parameter values. This will instruct Cloud Spanner to return the names and types of any query parameters in the statement. Fixes #35
| } | ||
|
|
||
| /** Extract Spanner type name from {@link java.sql.Types} code. */ | ||
| static String getSpannerTypeName(Type type, Dialect dialect) { |
There was a problem hiding this comment.
Would creating enum here( with both names for each type) improve readability?
In general another possibility could be to have a structure like a type manager for mapping pg, googlesql, java types, so the type checking and conversions like in functions such as ParameterTypeFromValue can also be simplified from one place?
There was a problem hiding this comment.
My plan was to add that to the Java client library instead of directly in the JDBC driver, so we can use it in more places. I've expedited that and added a PR for it here: googleapis/java-spanner#2763
When that has been merged, a new release of the client library has been cut, and the dependency in the JDBC driver updated to the new version, then we can simplify this implementation.
| JdbcParameterMetaData(JdbcPreparedStatement statement, ResultSet resultSet) { | ||
| this.statement = statement; | ||
| statement.getParameters().fetchMetaData(statement.getConnection()); | ||
| this.parameters = resultSet.getMetadata().getUndeclaredParameters(); |
There was a problem hiding this comment.
Based on my understanding of this field from Cloud Spanner code, UndeclaredParameters field only returns types for untyped parameters, i.e. when the types of the parameters are not passed in from the client and they are sent as proto.value.
So is this the case for all the prepared statements we execute from the JDBC driver?
There was a problem hiding this comment.
In this case the name of this field in the proto definition is a bit unfortunate. It says 'undeclared parameters', but it actually returns information about all parameters, including the ones that included a type and/or value when it was sent by the client. So if the user included type information for one or more parameters, it will also show up in this map.
🤖 I have created a release *beep* *boop* --- ## [2.15.0](https://togithub.com/googleapis/java-spanner-jdbc/compare/v2.14.6...v2.15.0) (2023-12-22) ### Features * Support PreparedStatement#getParameterMetaData() ([#1218](https://togithub.com/googleapis/java-spanner-jdbc/issues/1218)) ([721ff45](https://togithub.com/googleapis/java-spanner-jdbc/commit/721ff4552104efba47c19ef511282071c3b334c3)) ### Performance Improvements * Optimize isValid implementation ([#1444](https://togithub.com/googleapis/java-spanner-jdbc/issues/1444)) ([914e973](https://togithub.com/googleapis/java-spanner-jdbc/commit/914e973ad7fd638fabc3ec130b7618c51f01f401)), closes [#1443](https://togithub.com/googleapis/java-spanner-jdbc/issues/1443) ### Dependencies * Update dependency org.postgresql:postgresql to v42.7.1 ([#1441](https://togithub.com/googleapis/java-spanner-jdbc/issues/1441)) ([5997555](https://togithub.com/googleapis/java-spanner-jdbc/commit/59975553826360b86492e50b9d49c29aecc28bab)) --- This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
Add actual support for
PreparedStatement#getParameterMetaData(). The first time this method is called for aPreparedStatement, the connection will now callConnection#analyzeQueryorConnection#analyzeUpdatewithout any parameter values. This will instruct Cloud Spanner to return the names and types of any query parameters in the statement. The information that is returned is used to create an instance ofParameterMetaData.Previously, this class was only constructed with information based on values that had already been set on the statement, which meant that it could not be used to determine what types that Cloud Spanner expected for a given query parameter.
Fixes #35