mark at lawinegevaar.nl
Wed May 29 20:16:45 UTC 2019
On 2019-05-29 19:43, Lance Andersen wrote:
> When/if an update is made it will be in JDBC 4.4 as part of an MR.
> I do not have a timeframe for an MR as of this time. I am gathering
> small things for an MR but not at that point yet.
Ok, is adding SQL:2016 DECFLOAT (mapping to java.math.BigDecimal) to
Types and JDBCType also up for consideration for 4.4?
> Not sure there is a need for ConnectionBuilder to extend Wrapper given
> you can unwrap the Connection if needed.
I was thinking unwrapping might give a natural way to access vendor
specific extensions to ConnectionBuilder.
For example say there is a FooConnectionBuilder interface:
public interface FooConnectionBuilder extends java.sql.ConnectionBuilder
FooConnectionBuilder setBar(Bar bar);
Then you might access it through
DataSource ds = ..
That allows for a fluent continuation of the builder. It would also have
provided a more natural workaround for gssCredential() not being part of
the current API.
One thing I now notice, is that none of the other methods (except
build()) in ConnectionBuilder throw a SQLException, so maybe neither
should gssCrendential(..). It should also not be necessary to document a
"@throws SQLException if an error occurs." because adding the credential
to the builder should only have an effect on build().
The only question then remains what to do with implementations that
don't support this. Throwing UnsupportedOperationException instead of
SQLFeatureNotSupportedException might be an option, or implementations
could defer the exception until build() or just plain ignore it. On the
other hand throwing UnsupportedOperationException instead of
SQLFeatureNotSupportedException might be a deviation from the rest of
the JDBC API, and ignoring it is probably not a good idea either.
>> On May 29, 2019, at 1:25 PM, Mark Rotteveel <mark at lawinegevaar.nl>
>> On 28-5-2019 20:54, Douglas Surber wrote:
>>> We have received a request to add the following method to
>>> * Provide a GSSCredential to authenticate the connection with
>>> the server.
>>> * @param credential used to authenticate the connection. Not
>>> * @return this ConnectionBuilder
>>> * @throws SQLException if an error occurs.
>>> ConnectionBuilder gssCredential(org.ietf.jgss.GSSCredential
>>> credential) throws SQLException;
>>> Any thoughts?
>> It needs to be documented that this is an optional method, and the
>> documentation must include a @throws SQLFeatureNotSupportedException
>> to that effect. The default implementation should throw
>> Addition of this to ConnectionBuilder, also warrants the question if
>> a similar method should be added to javax.sql.CommonDataSource
>> (although maybe lifetime of credentials are a factor here)
>> Also, looking at ConnectionBuilder, shouldn't it extend
>> java.sql.Wrapper (eg to 'unwrap' to implementation specifics)?
>> BTW: In what form will these changes land, is there a JDBC 4.4 in
>> the works, or will these just be an update to the API without a
>> formal JDBC maintenance version?
>> Mark Rotteveel
>  
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>  http://oracle.com/us/design/oracle-email-sig-198324.gif
More information about the jdbc-spec-discuss