JDBC improvements and convenience method suggestions

[Mark Rotteveel]

On 12-7-2018 23:01, Vladimir Sitnikov wrote:
>>       "INSERT INTO t VALUES (?, ?, ?)")) {
>>       s.set(1, 2, 3);
>> I think that this should require that the provided parameters should
>> .include **all** parameters
> 
> How should it handle nulls?
> I'm fine if it throws in case null arguments are present, however it would
> limit the use of the feature.
> SQL deals with typed nulls, while Java has no way to tell if null is of
> numeric or text type.

Hmm, I hadn't thought about that possibility.

With Firebird/Jaybird, the type parameter is essentially ignored as the 
type is decided by the statement prepare (in theory it would be possible 
to override, but Jaybird doesn't support that, and there would be 
annoying edge cases to support/allow for that, instead it applies a 
conversion from supported object types to the known field type). So, for 
Jaybird using `setObject(idx, null)` will just work without having to 
supply a type `int` or `SQLType`.

This could indeed be a problem for those drivers that require type 
information with `setObject`.

I'm not sure what would be a good way to solve that though, except maybe 
creating a type that combines SQLType and the value (which might make 
this a bit ugly), and using that type for the vararg parameter. Or maybe 
create a SQLTyped null sentinel type, but that would be a bit 
counter-intuitive.

> Consider { call procedure(?) } when there are two overloads (text and
> numeric argument). The type of null enables to pick the proper overload.

Interesting example, Firebird itself doesn't support overloading stored 
procedures. I assume this runs into problems with other parts of the 
JDBC api as well (see below).

> Lukas>    // PreparedStatement
> Lukas>    connection.executeUpdate("INSERT INTO t VALUES (?, ?, ?)", 1, 2,
> 3);
> 
> The same corner case with NULLS.
> There should either be some standard-defined sentinel for typed null or NPE
> for null values. Both variants do not sound like a solution to me.

That would imply that this driver (I assume PostgreSQL?) doesn't 
actually prepare a call/statement on prepare. How would this work for 
`getParameterMetaData​()` right now? I would assume that the type 
information for parameter meta data should be usable in this case, or is 
that somehow undecided in this case?

Mark
-- 
Mark Rotteveel