db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <a...@golux.com>
Subject [PATCH] Derby-107, Phase I
Date Thu, 03 Feb 2005 18:12:46 GMT

Based on discussion from this derby-dev list and on my understanding of the changes that are
going to be required, I am 
proposing to submit the changes for Derby-107 (ODBC metadata support) in the following three
phases.  I will include 
more details about the separate phases with each patch that I submit.

Note: By "SAFE" in the following list, I mean that the changes can be made and Derby will
still fully adhere to the JDBC 
standard.

Phase I) Where it is SAFE to do so, cast CHAR columns to VARCHAR columns in the metadata result
sets.

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.

Phase III) Submit a patch that will automatically generate ODBC metadata statements at Derby
build time, and that will 
add support for such metadata statements in the Derby engine (so that ODBC clients using Derby
Network Server can use a 
Derby database).

The first two phases are for purposes of creating "common ground" between JDBC and OBDC metadata,
so that metadata 
queries can be shared as much as possible between the two types of clients.  The third phase
then adds additional, 
ODBC-specific support that is not in line with JDBC, and thus that should not be used for
JDBC clients.

----

Attached is a patch for Phase I:
"Where it is SAFE to do so, cast CHAR columns to VARCHAR columns in the metadata result sets."

Since the JDBC spec only requires that such columns be "String", and since both CHAR and VARCHAR
map to Java Strings, 
this change to the metadata queries remains in agreement with the JDBC specification.

At the same time, the ODBC specification states explicitly which columns have to be "CHAR"
and which have to be 
"VARCHAR".  Thus, with this patch, I am making a very light change to the Derby metadata statements
that, while keeping 
Derby in line with the JDBC standard, also allows Derby to re-use some of the JDBC queries
to satisfy ODBC requirements 
(thereby reducing the amount of dual metadata needed in the engine).

Note that most of the casting to VARCHAR is for an emptry string literal, '', which defaults
to CHAR in the Derby engine.

I made a small change to the "metadata.java" test so that the results of this patch are verifiable
on a regular basis, 
and I've updated the two corresponding master files to reflect this change.

I ran the full "derbyall" suite on my local machine with this patch applied, and everything
passed.

Comments/feedback are appreciated, else could someone commit when s/he has time?

Thanks,
Army

Mime
View raw message