db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: behavior of Statement.getGeneratedKeys()
Date Tue, 11 Jul 2006 00:48:41 GMT
Rick Hillegas wrote:

> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:

>>> This would help customers who want to get the type of a table's
>>> generated key from getGeneratedKeys() itself and not have to extract
>>> this information from a more complicated series of metadata calls.
>> I'm lost here, what's complicated about DatabaseMetaData.getColumns()?
> You're right. It's not that complicated. If the driver returns the JDBC4
> contents of DatabaseMetaData.getColumns(), you can loop through the
> results until you get to the row whose IS_AUTOINCREMENT column is set to
> YES. If the driver returns JDBC3 results, it looks a little busier to me:
> o Prepare a SELECT on the base table.
> o Get the corresponding ResultSetMetaData
> o Loop till you find the column index with
> ResultSetMetaData.isAutoIncrement() == true
> But JDBC is big so there could be a simpler scheme.

These seem reasonable. On the other hand, using getGeneratedKeys() to
determine the type & name of a table's generated key seems very very
unlikely to me. It would require that the application/tool can insert a
row of the correct shape, if the app/tool can do that, then it probably
already knows the columns's definition. Also some auto-discovering tool
seems unlikely to use getGeneratedKeys as it would require perturbing
the database by having a successful INSERT (though maybe a INSERT INTO
T(a,b,c) SELECT a,b,c FROM T WHERE 1=0 might work). Seems way too
contrived though to say getGeneratedKeys() is a useful tool for
gathering metadata.


View raw message