Expose more JDBC/R2DBC statement methods for dialect authors #5098
Conversation
| @@ -182,11 +182,7 @@ class JdbcPreparedStatement( | |||
| private val preparedStatement: PreparedStatement, | |||
| ) : SqlPreparedStatement { | |||
| override fun bindBytes(index: Int, bytes: ByteArray?) { | |||
| if (bytes == null) { | |||
There was a problem hiding this comment.
Not needed, the JDBC driver calls setNull for non primitive types itself.
| @@ -155,7 +156,7 @@ fun CoroutineScope.R2dbcDriver( | |||
| } | |||
|
|
|||
| // R2DBC uses boxed Java classes instead primitives: https://r2dbc.io/spec/1.0.0.RELEASE/spec/html/#datatypes | |||
| class R2dbcPreparedStatement(private val statement: Statement) : SqlPreparedStatement { | |||
There was a problem hiding this comment.
Exposed to allow casting to a driver specific Statement to access driver methods.
| "use bindObject with generics instead", | ||
| ReplaceWith("bindObject<T>", ""), | ||
| ) | ||
| fun bindObject(index: Int, any: Any?, ignoredSqlType: Int) { |
There was a problem hiding this comment.
This ignoredSqlType parameter is needed because the dialect does not know if it is generating sync or async code. Ideally, we would have two dialects focussing on sync/async or we push the Gradle flag down to the dialect. I am okay with both.
| @@ -261,20 +253,28 @@ class JdbcPreparedStatement( | |||
| } | |||
| } | |||
|
|
|||
| fun bindObjectOther(index: Int, obj: Any?) { | |||
| fun bindObject(index: Int, obj: Any?, type: Int) { | |||
There was a problem hiding this comment.
I think this makes this a binary-incompatible change, right?
There was a problem hiding this comment.
Yes, we can also keep it but it's only used by the Postgres driver.
And according to Alec only the runtime needs to be api compatible.
There was a problem hiding this comment.
I think that was pre-2.0.
There was a problem hiding this comment.
Binary compatibility matters less for a driver like R2DBC which is still more "experimental", but the JDBC driver is widely used (and the SQLite one is an implementation of it) so we should definitely maintain compatibility for it.
We should enable the API dumper plugin!
There was a problem hiding this comment.
💁 I can refactor uses of bindObjectOther in the Postgres dialect to use this new api once it has been merged, then remove bindObjectOther before any new release.
bindObjectOther has only recently been added in the snapshot builds - so can be changed.
There was a problem hiding this comment.
I can refactor uses of bindObjectOther
This is already part of this PR, but thanks.
It's only recently been added in the snapshot builds - so can be changed.
In this case I agree, we can change it.
We should enable the API dumper plugin!
Yes, will do it in another PR.
Oracle JDBC requires the correct
java.sql.Typeswhen usingstatement.setNullinsetObject, so sqldelight should expose an overload too.At the moment I am forced to implement my own jdbc driver.