feat: add methods for unwrapping Spanner client #1914
Conversation
product-auto-label
bot
added
size: m
Adds methods for unwrapping the underlying DatabaseClient and Spanner instance that is used by a JDBC connection.
olavloite
force-pushed
the
unwrap-spanner-client
branch
from
456fbd4 to
f22db16
Compare
| * Connection}, e.g. starting a read/write transaction on the {@link DatabaseClient} will not | ||
| * start a transaction on this connection. | ||
| */ | ||
| default DatabaseClient getDatabaseClient() { |
There was a problem hiding this comment.
Can customer do something like below?
CloudSpannerJdbcConnection spannerJdbcConnection =
connection.unwrap(CloudSpannerJdbcConnection.class);
List<String> ddl =
spannerJdbcConnection
.getSpanner()
.getDatabaseClient()
Is there any difference between this and the exposed method? I mean do we need to expose a seperate method for getDatabaseClient?
There was a problem hiding this comment.
At the moment, there is no difference, as the only key that is used to determine which DatabaseClient to get from a Spanner instance is the DatabaseId. But this might change in the future, for example when #1856 is resolved. With this, the JDBC driver might use additional properties to determine which DatabaseClient is used for a connection.
| public DatabaseId getDatabaseId() { | ||
| return this.options.getDatabaseId(); | ||
| } | ||
|
|
||
| @Override | ||
| public DatabaseClient getDatabaseClient() { | ||
| return getSpannerConnection().getDatabaseClient(); | ||
| } |
There was a problem hiding this comment.
interested to understand if there is a customer usecase where they would like to use databaseclient directly instead of using the connection.
There was a problem hiding this comment.
It is more of an 'escape hatch'. We try to support most features directly in the JDBC driver, but some Spanner features don't have a good equivalent in JDBC. In those cases, it can be easier to just use the database client directly. One such example could for example be BatchWrite. Although we can also create a method in the JDBC Connection that just delegates the call directly to the underlying database client, giving the option of just unwrapping the client ensures that all features are usable, even if there is no such delegate method.
Adds methods for unwrapping the underlying DatabaseClient and Spanner instance that is used by a JDBC connection.