FirebirdSQL / jaybird

JDBC driver for Firebird

Home Page:https://www.firebirdsql.org/en/jdbc-driver/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

DatabaseMetadata getTypeInfo() does not handle autoincrements

prrvchr opened this issue · comments

It seems that none of the types supporting autoincrement are declared in the result set produced by getTypeInfo().
Normally SMALLINT, INTEGER, and BIGINT types should answer True in column 12 (AUTO_INCREMENT).

I think there is the same problem with the value returned by ResultSetMetaData.isAutoIncrement(int column) which is never true. This prevents any recognition of autoincrement columns.

Identifying this type of information - for ResultSetMetaData - requires additional queries to the metadata tables, as such information is not available in the normal column metadata returned when preparing a statement. It can be added, but that will introduce overhead when asking for that information.

With regards to getTypeInfo(), that is indeed a bug/oversight. I will split that off to a separate ticket.

Correction, I will split off the ResultSetMetaData to a separate ticket.

Also to be backported to 5.0.5.

Thank you for taking care of this problem.

Looking at the ODBC documentation of GetTypeInfo(), the column AUTO_INCREMENT (renamed to AUTO_UNIQUE_VALUE in ODBC 3.0) should only report true for types when the type is definitely auto-increment (e.g. like PostgreSQL's BIGSERIAL type). Similarly looking at the X/Open SQL CLI standard with regard to GetTypeInfo() (which is the basis for both JDBC and (older) ODBC for these methods), it says:

This column contains SQL_TRUE if a column of this data type is automatically set to a unique value when a row is inserted.* Otherwise, this column contains SQL_FALSE.

With the footnote (*):

Columns of this data type are generally not updatable and the value remains constant for the life of the row.

Similarly, in ISO/IEC-9075-3:2003 (SQL:2003:CLI, basically the successor to X/Open SQL CLI):

l) The value of AUTO_UNIQUE_VALUE is
  Case:
    i) If a column of this data type is set to a value unique among all rows of that column when a row is inserted, then 1 (one).
    ii) Otherwise, 0 (zero).

In other words, the type info for SMALLINT, INTEGER and BIGINT should not report true for AUTO_INCREMENT, because they do not conform to this definition (only when they are declared together with GENERATED {ALWAYS | BY DEFAULT} AS IDENTITY). As such, I will close this as it's working as it should.

For comparison, the PostgreSQL JDBC driver only reports true for SERIAL, BIGSERIAL and SMALLSERIAL, which fits because those types definitely generate a value on each insert.

Hi Mark,

I don't know enough about JDBC specifications, and even less about ODBC specifications, to be able to say how to interpret them.

On the other hand, I have 7 JDBC drivers which work under Base (I still have to manage the foreign keys) and all the differences between these drivers are recorded in a Drivers.xcu xml file.

In this file, thanks to the TypeInfoSettings option, I can patch the result of getTypeInfo() in order to obtain the correct resultset. Only two drivers need these modifications: PostgreSQL and Firebird. I also have this option for HsqlDB but it is only to allow the entry of the precision (from 0 to 6) for TIMESTAMP, TIMESTAMP WITH TIMEZONE, etc..., when creating a table or modifying the type of a column in a table.

And if I look at why Base needs this information, I understand that to declare a column with the identity constraint it must know the types that support the identity constraint.

Because if I refer to your interpretation then if this information is only provided for types which are definitely auto-incremented then this information is of very little interest.

How do I know the types supporting the GENERATED ALWAYS AS IDENTITY command when creating a table or modifying the type of a column if this information is not available?

On the other hand, this problem does not pose a problem for me because it is easy for me (using the TypeInfoSettings option) to get around it. So I'll let you interpret it however you want.

But, I have the same problem with ResutsetMetaData (issue #793) and I hope you will find a solution....