Thread: JDBC 3.0 support?

JDBC 3.0 support?

From
Hanasaki JiJi
Date:
any target date for a JDBC3.0 compliant driver?
--
=================================================================
= Management is doing things right; leadership is doing the     =
=       right things.    - Peter Drucker                        =
=_______________________________________________________________=
=     http://www.sun.com/service/sunps/jdc/javacenter.pdf       =
=  www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone  =
=================================================================


Re: JDBC 3.0 support?

From
Barry Lind
Date:
The driver does support jdbc3.0.  However that support is not 100%
complete (but then neither is the jdbc2 nor jdbc1 support 100% either).
  So the real question is what isn't there that you are looking for?

thanks,
--Barry

Hanasaki JiJi wrote:
> any target date for a JDBC3.0 compliant driver?


Re: JDBC 3.0 support?

From
Hanasaki JiJi
Date:
primarily - ResultSet resultSet = statement.getGeneratedKeys();

Barry Lind wrote:
> The driver does support jdbc3.0.  However that support is not 100%
> complete (but then neither is the jdbc2 nor jdbc1 support 100% either).
>  So the real question is what isn't there that you are looking for?
>
> thanks,
> --Barry
>
> Hanasaki JiJi wrote:
>
>> any target date for a JDBC3.0 compliant driver?
>
>
>
>

--
=================================================================
= Management is doing things right; leadership is doing the     =
=       right things.    - Peter Drucker                        =
=_______________________________________________________________=
=     http://www.sun.com/service/sunps/jdc/javacenter.pdf       =
=  www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone  =
=================================================================


Re: JDBC 3.0 support?

From
Barry Lind
Date:
Hanasaki,

The driver is already 3.0 compliant for that.  It correctly returns
false to DatabaseMetaData.supportsGetGeneratedKeys() indicating that
postgresql does not support this functionality.  This isn't likely to
change unless some significant new functionality is introduced in the
server to do this.  There isn't really anything the driver can do here
since the functionality doesn't exist in the database to automatically
return this information.

thanks,
--Barry


Hanasaki JiJi wrote:
> primarily - ResultSet resultSet = statement.getGeneratedKeys();
>
> Barry Lind wrote:
>
>> The driver does support jdbc3.0.  However that support is not 100%
>> complete (but then neither is the jdbc2 nor jdbc1 support 100%
>> either).  So the real question is what isn't there that you are
>> looking for?
>>
>> thanks,
>> --Barry
>>
>> Hanasaki JiJi wrote:
>>
>>> any target date for a JDBC3.0 compliant driver?
>>
>>
>>
>>
>>
>


Re: JDBC 3.0 support?

From
Hanasaki JiJi
Date:
Any suggestions for architecture/implemenation in the following situation:?
    - insert a new row
    - primary key is an autoinc / sequence column
    - no other column is sure to be unique
    - need to continue working with the data of the row
        after the insert and possibly do an update

Barry Lind wrote:
> Hanasaki,
>
> The driver is already 3.0 compliant for that.  It correctly returns
> false to DatabaseMetaData.supportsGetGeneratedKeys() indicating that
> postgresql does not support this functionality.  This isn't likely to
> change unless some significant new functionality is introduced in the
> server to do this.  There isn't really anything the driver can do here
> since the functionality doesn't exist in the database to automatically
> return this information.
>
> thanks,
> --Barry
>


Re: JDBC 3.0 support?

From
Tom Lane
Date:
Barry Lind <blind@xythos.com> writes:
> The driver is already 3.0 compliant for that.  It correctly returns
> false to DatabaseMetaData.supportsGetGeneratedKeys() indicating that
> postgresql does not support this functionality.  This isn't likely to
> change unless some significant new functionality is introduced in the
> server to do this.

What exactly would the server need to do to support this?  Do you think
the effort is warranted?

            regards, tom lane


Re: JDBC 3.0 support?

From
Barry Lind
Date:
Tom,

This essentially would rely on the 'returning' functionality that has
been discussed previously on hackers.  Specifically the spec states that
the database should return all 'auto generated keys' or specifically
requested columns for inserted rows.  However the proposals I have seen
for 'returning' are done through a returning sql clause.  This would
mean the jdbc driver would need to parse the user supplied sql and
insert the correct returning clause into the proper location in the sql
statement.  It also means that the driver would need a way to determine
which columns were 'auto generated' (which shouldn't be too difficult
for serial columns, but if the auto-generating mechanism was a trigger
or a default clause, I am not sure how that would be done).

Here is what the spec
(http://java.sun.com/products/jdbc/download.html#corespec30) says:

13.6 Retrieving Auto Generated Keys

Many database systems have a mechanism that automatically generates a
unique key field when a row is inserted. The method
Statement.getGeneratedKeys, which can be called to retrieve the value of
such a key, returns a ResultSet object with a column for each
automatically generated key. A flag indicating that any auto generated
columns should be returned is passed to the methods execute,
executeUpdate or prepareStatement when the statement is executed or
prepared.

Additional methods allow the ordinals or names of the columns that
should be returned to be specified.

Calling ResultSet.getMetaData on the ResultSet object returned by
getGeneratedKeys will produce a ResultSetMetaData object that can be
used to determine the number, type and properties of the generated keys.

In some cases, such as in an insert select statement, more than one key
may be returned. The ResultSet object returned by getGeneratedKeys will
contain a row for each key that a statement generated. If no keys are
generated, an empty result set will be returned.

The concurrency of the ResultSet object returned by getGeneratedKeys
must be CONCUR_READ_ONLY. The type of the ResultSet object must be
either TYPE_FORWARD_ONLY or TYPE_SCROLL_INSENSITIVE.

The method DatabaseMetaData.supportsGetGeneratedKeys returns true if a
JDBC driver and underlying data source support the retrieval of
automatically generated keys.


thanks,
--Barry



Tom Lane wrote:
> Barry Lind <blind@xythos.com> writes:
>
>>The driver is already 3.0 compliant for that.  It correctly returns
>>false to DatabaseMetaData.supportsGetGeneratedKeys() indicating that
>>postgresql does not support this functionality.  This isn't likely to
>>change unless some significant new functionality is introduced in the
>>server to do this.
>
>
> What exactly would the server need to do to support this?  Do you think
> the effort is warranted?
>
>             regards, tom lane
>


Re: JDBC 3.0 support?

From
Dave Cramer
Date:
INSERT .... RETURNING will work here, but in the meantime

select nextval('sequence_name');
insert into (id,....) values ( result from above, ....)
continue working

Dave
On Tue, 2003-05-06 at 23:13, Hanasaki JiJi wrote:
> Any suggestions for architecture/implemenation in the following situation:?
>     - insert a new row
>     - primary key is an autoinc / sequence column
>     - no other column is sure to be unique
>     - need to continue working with the data of the row
>         after the insert and possibly do an update
>
> Barry Lind wrote:
> > Hanasaki,
> >
> > The driver is already 3.0 compliant for that.  It correctly returns
> > false to DatabaseMetaData.supportsGetGeneratedKeys() indicating that
> > postgresql does not support this functionality.  This isn't likely to
> > change unless some significant new functionality is introduced in the
> > server to do this.  There isn't really anything the driver can do here
> > since the functionality doesn't exist in the database to automatically
> > return this information.
> >
> > thanks,
> > --Barry
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Dave Cramer <Dave@micro-automation.net>