Thread: summary of new features in JDBC 3.0
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
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
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
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
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