db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject [PATCH] Derby-107, Phase II
Date Fri, 11 Feb 2005 16:21:04 GMT

For background on this patch and for the "Phase I" patch that precedes this one, please see
the email:

http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200502.mbox/%3c4202699E.3000009@golux.com%3e

*** NOTE TO COMMITTERS: *** This patch is BASED ON THE PHASE I PATCH as a starting point.
 Therefore, please do NOT
commit this patch until _after_ the Phase I patch has been committed.  I posted the Phase
I patch to derby-dev last week
(Feb 3rd); it can be referenced at the link given above.

I have run the derbyall test suite with these changes, using Windows with Sun JDK 1.4.2, and
have included the relevant
master updates as part of the patch.

----

Attached is a patch for Phase II of my proposal for fixing Derby-107:

"Phase II) Where it is SAFE to do, modify the values of non-numeric rows in the metadata result
sets to be NULL when the
columns in question don't apply.  For example, "SCALE/DECIMAL_DIGITS" and "NUM_PREC_RADIX"
are two columns that wouldn't
apply to a row that is for CHAR, and thus the values in those two columns (for that specific
row) would be NULL."
   -- Pasted from my first email referenced above.

The JDBC specification for some metadata result set columns doesn't state what value should
be returned if a given
column doesn't apply to a given row.  For example, the JDBC 3.0 API has the following brief
descriptions for the
DatabaseMetaData.getColumns() API:

5.  DATA_TYPE int => SQL type from java.sql.Types
...
9.  DECIMAL_DIGITS int => the number of fractional digits
10. NUM_PREC_RADIX int => Radix (typically either 10 or 2)

The API doesn't dictate what the values for DECIMAL_DIGITS and NUM_PREC_RADIX should be with
rows for which the value of
DATA_TYPE is a _non-numeric_ type.  Or at least, I can't find that information stated anywhere.

Thus, my own conclusion here is that a database which returns NULL for these values when they
don't apply is still
compliant with the JDBC standard, since the standard doesn't say otherwise.  If anyone can
prove that this is the wrong
conclusion, please feel free to say so.

That said, the ODBC specification for "SQLColumns", which is the ODBC equivalent of "getColumns",
_does_ state that
certain values, like DECIMAL_DIGITS and NUM_PREC_RADIX, _should_ be NULL if they do not apply
to the row in question
and/or if the row is non-numeric.

Therefore, this patch (Phase II for Derby-107) changes the existing Derby metadata so that
values which are only defined
for numeric columns, like DECIMAL_DIGITS and NUM_PREC_RADIX, will return NULL for non-numeric
columns and for numeric
columns to which they do not apply.  This change allows us to use the same result sets to
satisfy both JDBC and ODBC
(via Network Server) metadata requests in regards to this particular issue.

Details of the patch:

This patch changes the following result set columns (by altering the org/apache/derby/impl/jdbc/metadata.properties
file):

1. SCALE/DECIMAL_DIGITS => Changed to return NULL for non-numeric columns and for columns
having non-exact numeric types
(meaning java.sql.DOUBLE, java.sql.FLOAT, and java.sql.REAL).  Derby currently returns "0"
for these columns.

This change applies to the following metadata methods: getProcedureColumns, getColumns, getBestRowIdentifier.

2. MINIMUM_SCALE, MAXIMUM_SCALE => Changed to return NULL for non-numeric columns and for
columns having non-exact
numeric types (meaning java.sql.DOUBLE, java.sql.FLOAT, and java.sql.REAL).  Derby currently
returns "0" for these columns.

This change applies to the following metadata methods: getTypeInfo.

3. RADIX/NUM_PREC_RADIX => Changed to return NULL for non-numeric columns.  Derby currently
returns "10" for these columns.

This change applies to the following metadata methods: getProcedureColumns, getColumns, getTypeInfo.

----

Once again, just to reiterate:

** This patch was created with respect to the Phase I patch, and thus should not be committed
until after the Phase I
patch has been committed.

** I have run the derbyall test suite with these changes, using Windows with Sun JDK 1.4.2,
and have included the
relevant master updates as part of the patch.

Thanks,
Army


Mime
View raw message