db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject Questions about "getApproximateLengthInBytes()"
Date Fri, 25 Mar 2005 22:57:08 GMT

I was looking yet again at some of Derby's metadata code, and I noticed that for the getProcedureColumns()
method, the 
"LENGTH" value of the result set is supposed to be "length in bytes" (per JDBC spec).  However,
the value as assigned in 
the org.apache.derby.catalog.GetProcedureColumns class is really just the value of getMaximumWidth(),
which doesn't seem 

For example, a column defined as "CHAR(10)" has a max width of 10, but the length in bytes
should be "20" since Java 
uses two bytes per character.  Thus the current Derby code will return the wrong value for
LENGTH with this metadata call.

As I was looking into this problem, I found a method in TypeId.java called "getApproximateLengthInBytes()"
that is 
apprently supposed to return the length of a column in bytes--i.e. it's just what we need
for the metadata.  While 
looking at the method, though, I had some questions, and I'm wondering if anyone out there
knows any of the answers...

1) Why the "+ 2" in the following case?

       case StoredFormatIds.CHAR_TYPE_ID:
       case StoredFormatIds.NATIONAL_CHAR_TYPE_ID:
            return (2 * dts.getMaximumWidth()) + 2;

2) Why the value "200" in this case?  It's used throughout the method whenever Integer.MAX_VALUE
is encountered--is 
there a reason we use the specific value of 200?  What does it mean, and how/where is it interpreted
by Derby?  Also, 
why the "8 +" in the else clause?

       case StoredFormatIds.DECIMAL_TYPE_ID:
            // Return 200 if precision is max int
            if (dts.getPrecision() == Integer.MAX_VALUE)
                   return 200;
                   return 8 + (int) (Math.ceil(((double)dts.getPrecision())/2d));

3) Why the "10240" in the follwowing case?  What does it mean, and how/where is it interpreted
by Derby?

       case StoredFormatIds.LONGVARBIT_TYPE_ID:
       case StoredFormatIds.BLOB_TYPE_ID:
       case StoredFormatIds.CLOB_TYPE_ID:
       case StoredFormatIds.NCLOB_TYPE_ID:
            return 10240;

4) For datetime values, there is the following code:

        ** For Date/time we know the exact size
        ** thanks to some investigative work by
        ** someone or other (sad isn't it).
        case StoredFormatIds.DATE_TYPE_ID:
            return 18;
        case StoredFormatIds.TIME_TYPE_ID:
            return 16;
        case StoredFormatIds.TIMESTAMP_TYPE_ID:
            return 29;

Does anyone know how these values were calculated?  I.e. what "investigative work" led to
these results?  Are they still 

5) Generally speaking, would it be acceptable to use this method for metadata LENGTH queries,
instead of the current 
(and incorrect) "getMaximumLength()" call?

Also, as a general question, are these values the same for Network Server?  I.e. for a given
type, does Network Server 
transfer the same (approximate) number of bytes as reported by this method, or does Network
Server do it's own thing?  I 
looked at the FdocaConstants class in Network Server and I noticed that the "outlen" field
of the 
"mapJdbcTypeToDrdaType" method matches the above numbers in most cases EXCEPT for the datetime
values--so is there a 
difference between the number of bytes used for datetime values in Embedded mode vs. that
used/transferred in Network 
Server mode?

Anyone know the answers to any of these questions?

Thanks much,

View raw message