Thread: summary of new features in JDBC 3.0

summary of new features in JDBC 3.0

From
Vadim Nasardinov
Date:
This is probably asking too much, but I was wondering if anyone could
assign a current perceived priority to each of the new features
introduced in JDBC 3.0 in terms of whether and when they will be
supported by the PostgreSQL JDBC driver.

The list has been lifted from Chapter 3 of the spec:

    * Savepoint support
    * Reuse of prepared statements by connection pools
    * Connection pool configuration
    * Retrieval of parameter metadata
    * Retrieval of auto-generated keys
    * Ability to have multiple open ResultSet objects
    * Passing parameters to CallableStatement objects by name
    * Holdable cursor support
    * BOOLEAN data type
    * Making internal updates to the data in Blob and Clob objects
    * Retrieving and updating the object referenced by a Ref object
    * Updating of columns containing BLOB, CLOB, ARRAY and REF types
    * DATALINK/URL data type
    * Transform groups and type mapping
    * Relationship between the JDBC SPI (Service Provider Interface) and
      the Connector architecture
    * DatabaseMetadata APIs


Thanks,
Vadim


Re: summary of new features in JDBC 3.0

From
Oliver Jowett
Date:
Vadim Nasardinov wrote:
> This is probably asking too much, but I was wondering if anyone could
> assign a current perceived priority to each of the new features
> introduced in JDBC 3.0 in terms of whether and when they will be
> supported by the PostgreSQL JDBC driver.

You might want to look at the driver todo list:
http://jdbc.postgresql.org/todo.html

Also note that for much of the stuff that we do not implement, we say
that we don't implement it in our metadata responses. JDBC3 compliance
doesn't require that you support all the bells and whistles, just that
you have a minimum feature set and have accurate metadata, IIRC.

>     * Savepoint support

Implemented.

>     * Reuse of prepared statements by connection pools

Not implemented. From memory this is transparent to the JDBC user
anyway. It's on the todo list.

>     * Connection pool configuration

What does this entail? Aren't connection pools in the realm of the
appserver?

>     * Retrieval of parameter metadata

Not implemented. This can probably be supported with a V3 connection and
a statement Describe.

>     * Retrieval of auto-generated keys

Not implemented. Probably needs backend support. See the todo list.

>     * Ability to have multiple open ResultSet objects

Implemented.

>     * Passing parameters to CallableStatement objects by name

Unlikely to happen until there is backend support for passing function
parameters by name (or is this something different?)

>     * Holdable cursor support

Not implemented. See the todo list.

>     * BOOLEAN data type

Implemented. This is just an alias for BIT.

>     * Making internal updates to the data in Blob and Clob objects

I assume this is the positioned write stuff? Not implemented, but
doesn't look too hard to do. See the todo list.

>     * Retrieving and updating the object referenced by a Ref object

Not implemented. The backend does not support REF.

>     * Updating of columns containing BLOB, CLOB, ARRAY and REF types

We don't support REF, see above.

The other types are not implemented, but given that we support them in
PreparedStatement there's no real reason we can't support updates too.

>     * DATALINK/URL data type

Not implemented. The backend does not support DATALINK/URL. We could
possibly just map this to VARCHAR?

>     * Transform groups and type mapping

If this is the SQL type maps stuff, then not implemented. Kris is
working on SQLInput/SQLOutput implementations that would allow this to
be implemented. See the todo list.

>     * Relationship between the JDBC SPI (Service Provider Interface) and
>       the Connector architecture

I don't think this imposes any implementation requirements on the driver?

>     * DatabaseMetadata APIs

We implement all the methods, but I don't know how accurate the returned
values are. There are some resultset-returning methods that should
return additional columns in JDBC3 that haven't been implemented yet.
See the todo list.

-O

Re: summary of new features in JDBC 3.0

From
Dave Cramer
Date:
Vadim,

What would be really useful are test cases for all of the below, even if
they fail.

Dave

Vadim Nasardinov wrote:

>This is probably asking too much, but I was wondering if anyone could
>assign a current perceived priority to each of the new features
>introduced in JDBC 3.0 in terms of whether and when they will be
>supported by the PostgreSQL JDBC driver.
>
>The list has been lifted from Chapter 3 of the spec:
>
>    * Savepoint support
>    * Reuse of prepared statements by connection pools
>    * Connection pool configuration
>    * Retrieval of parameter metadata
>    * Retrieval of auto-generated keys
>    * Ability to have multiple open ResultSet objects
>    * Passing parameters to CallableStatement objects by name
>    * Holdable cursor support
>    * BOOLEAN data type
>    * Making internal updates to the data in Blob and Clob objects
>    * Retrieving and updating the object referenced by a Ref object
>    * Updating of columns containing BLOB, CLOB, ARRAY and REF types
>    * DATALINK/URL data type
>    * Transform groups and type mapping
>    * Relationship between the JDBC SPI (Service Provider Interface) and
>      the Connector architecture
>    * DatabaseMetadata APIs
>
>
>Thanks,
>Vadim
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faqs/FAQ.html
>
>
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561


Re: summary of new features in JDBC 3.0

From
Vadim Nasardinov
Date:
On Wednesday 27 October 2004 17:16, Oliver Jowett wrote:
> >     * Connection pool configuration
>
> What does this entail?

Section 3.1 (p. 21) of the spec says,

  | * Connection pool configuration
  |
  |   Defined a number of properties for the ConnectionPoolDataSource
  |   interface. These properties can be used to describe how
  |   PooledConnection objects created by DataSource objects should be
  |   pooled.

From my cursory reading of some of the sections that seem relevant, I
think this means the following. Section 9.4.1 "DataSource Properties"
(p. 58) defines the following DataSource properties:

 TABLE 9-1 Standard Data Source Properties

 +------------------------------------------------------------------------+
 |  Property Name  |  Type  |                 Description                 |
 |-----------------+--------+---------------------------------------------|
 | databaseName    | String | name of a particular database on a server   |
 |-----------------+--------+---------------------------------------------|
 | dataSourceName  | String | a data source name; used to name an         |
 |                 |        | underlying XADataSource object or           |
 |                 |        | ConnectionPoolDataSource object when        |
 |                 |        | pooling of connections is done              |
 |-----------------+--------+---------------------------------------------|
 | description     | String | description of this data source             |
 |-----------------+--------+---------------------------------------------|
 | networkProtocol | String | network protocol used to communicate with   |
 |                 |        | the server                                  |
 |-----------------+--------+---------------------------------------------|
 | password        | String | a database password                         |
 |-----------------+--------+---------------------------------------------|
 | portNumber      | int    | port number where a server is listening for |
 |                 |        | requests                                    |
 |-----------------+--------+---------------------------------------------|
 | roleName        | String | the initial SQL rolename                    |
 |-----------------+--------+---------------------------------------------|
 | serverName      | String | database server name                        |
 |-----------------+--------+---------------------------------------------|
 | user            | String | user 's account name                        |
 +------------------------------------------------------------------------+


In addition to these, Section 11.7 "ConnectionPoolDataSource
Properties" (p. 78), defines these:

 TABLE 11-1  Standard Connection Pool Properties

 +------------------------------------------------------------------------+
 |  Property Name  | Type |                  Description                  |
 |-----------------+------+-----------------------------------------------|
 | maxStatements   | int  | The total number of statements that the pool  |
 |                 |      | should keep open. 0 (zero) indicates that     |
 |                 |      | caching of statements is disabled.            |
 |-----------------+------+-----------------------------------------------|
 | initialPoolSize | int  | The number of physical connections the pool   |
 |                 |      | should contain when it is created             |
 |-----------------+------+-----------------------------------------------|
 | minPoolSize     | int  | The number of physical connections the pool   |
 |                 |      | should keep available at all times. 0 (zero)  |
 |                 |      | indicates that connections should be created  |
 |                 |      | as needed.                                    |
 |-----------------+------+-----------------------------------------------|
 | maxPoolSize     | int  | The maximum number of physical connections    |
 |                 |      | that the pool should contain. 0 (zero)        |
 |                 |      | indicates no maximum size.                    |
 |-----------------+------+-----------------------------------------------|
 | maxIdleTime     | int  | The number of seconds that a physical         |
 |                 |      | connection should remain unused in the pool   |
 |                 |      | before the connection is closed. 0 (zero)     |
 |                 |      | indicates no limit.                           |
 |-----------------+------+-----------------------------------------------|
 | propertyCycle   | int  | The interval, in seconds, that the pool       |
 |                 |      | should wait before enforcing the current      |
 |                 |      | policy defined by the values of the above     |
 |                 |      | connection pool properties                    |
 +------------------------------------------------------------------------+


> Aren't connection pools in the realm of the appserver?

Perhaps.  I can neither confirm nor deny untill I read the spec, which I
haven't done yet.

> >     * Making internal updates to the data in Blob and Clob objects
>
> I assume this is the positioned write stuff? Not implemented, but
> doesn't look too hard to do. See the todo list.

Yes, I think you're right.  The spec says (Section 3.1):

  | * Making internal updates to the data in Blob and Clob objects
  |
  |   Added methods to allow the data contained in Blob and Clob objects
  |   to be altered.

They appear to be talking about these added methods:
  http://people.redhat.com/~vadimn/scratch/pgsql-jdbc/api-diff/java.sql.Blob.html
  http://people.redhat.com/~vadimn/scratch/pgsql-jdbc/api-diff/java.sql.Clob.html

> >     * Transform groups and type mapping
>
> If this is the SQL type maps stuff, then not implemented. Kris is
> working on SQLInput/SQLOutput implementations that would allow this
> to be implemented. See the todo list.

I'm not sure what this is about.  First time I've ever heard of
"transform groups".  Section 3.1 says

  | * Transform groups and type mapping
  |
  |   Described the effect of transform groups and how this is
  |   reflected in the metadata.


Section 17.5 "Effect of Transform Groups" goes on to say

  | Transform groups (SQL99) can be used to convert a user-defined SQL
  | type into predefined SQL types. This transformation is performed
  | by the underlying data source before it is returned to the JDBC
  | driver.
  |
  | If transform groups are used for a user-defined type, and the
  | application has not defined a mapping for that type to a Java
  | class, then the ResultSetMetaData method getColumnClass should
  | return the Java class corresponding to the data type produced by
  | the transformation function (that is, String for a VARCHAR).


> >     * Relationship between the JDBC SPI (Service Provider Interface) and
> >       the Connector architecture
>
> I don't think this imposes any implementation requirements on the driver?

I think it does, if you choose to implement what Section 19.2 refers
to as the "Mapping Connector System Contracts to JDBC Interfaces".

Thanks for your answers.


Vadim


Re: summary of new features in JDBC 3.0

From
Oliver Jowett
Date:
Vadim Nasardinov wrote:

> In addition to these, Section 11.7 "ConnectionPoolDataSource
> Properties" (p. 78), defines these:
>
>  TABLE 11-1  Standard Connection Pool Properties
>
>  +------------------------------------------------------------------------+
>  |  Property Name  | Type |                  Description                  |
>  |-----------------+------+-----------------------------------------------|
>  | maxStatements   | int  | The total number of statements that the pool  |
>  |                 |      | should keep open. 0 (zero) indicates that     |
>  |                 |      | caching of statements is disabled.            |
>  |-----------------+------+-----------------------------------------------|
>  | initialPoolSize | int  | The number of physical connections the pool   |
>  |                 |      | should contain when it is created             |
>  |-----------------+------+-----------------------------------------------|
>  | minPoolSize     | int  | The number of physical connections the pool   |
>  |                 |      | should keep available at all times. 0 (zero)  |
>  |                 |      | indicates that connections should be created  |
>  |                 |      | as needed.                                    |
>  |-----------------+------+-----------------------------------------------|
>  | maxPoolSize     | int  | The maximum number of physical connections    |
>  |                 |      | that the pool should contain. 0 (zero)        |
>  |                 |      | indicates no maximum size.                    |
>  |-----------------+------+-----------------------------------------------|
>  | maxIdleTime     | int  | The number of seconds that a physical         |
>  |                 |      | connection should remain unused in the pool   |
>  |                 |      | before the connection is closed. 0 (zero)     |
>  |                 |      | indicates no limit.                           |
>  |-----------------+------+-----------------------------------------------|
>  | propertyCycle   | int  | The interval, in seconds, that the pool       |
>  |                 |      | should wait before enforcing the current      |
>  |                 |      | policy defined by the values of the above     |
>  |                 |      | connection pool properties                    |
>  +------------------------------------------------------------------------+

I never understood why these properties were there. The
ConnectionPoolDataSource does not own and manage the connection pool
(despite the misleading name) -- it just provides the primitives so that
a pooling implementation can be built on top of it -- so why do the
properties live there?

I wonder if it is a persistent typo in the spec, and those properties
are actually meant to manage the statement pool, not the connection
pool. That would make more sense since the statement pool lives entirely
inside the datasource.

As it is, maxStatements is the only one that makes any sort of sense..

-O