db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander, Arthur (Art) B230" <Art.Alexan...@CIGNA.COM>
Subject RE: Questions about "getApproximateLengthInBytes()"
Date Mon, 04 Apr 2005 22:45:14 GMT
Dan wrote:

> With JDBC and Derby the stored (on-disk) byte size of 
> a type or value is not meant to be exposed to the application. 

What if you are writing a DBA type tool?  Wouldn't be helpful to
have exposed the "on-disk" size, so that the DBA tool can help 
the DBA plan the number of rows per page, etc.?

Maybe this is a separate interface that the Type supports, but 
the Tool Vendor must be aware to cast the Type to if they wish
to expose that level of detail information?  The default app.
view would be exposed through another application level interface
that would represent TYPE to the end-user programmer application 

Art Alexander

-----Original Message-----
From: Daniel John Debrunner [mailto:djd@debrunners.com] 
Sent: Monday, April 04, 2005 6:37 PM
To: Derby Development
Subject: Re: Questions about "getApproximateLengthInBytes()"

Army wrote:

> My question is whether or not a declaration of maximum BYTE length for
> the Derby builtin types exists somewhere in the codeline, and if so,
> it okay to use that for the metadata calls?  And on that premise, I
> looking at "getApproximateLengthInBytes" to see if that method has the
> info required (hence my initial email on this subject).

As I said in Derby-194, the definition of length needs to be precise,
length of what exactly. Since Derby is written in Java and its interface
is JDBC then 'length' as in the C sizeof operator is not applicable.
Take DATE as an example, with JDBC/Derby there is no way to convert a
DATE value to/from a byte array, so its length in bytes has no meaning.

Now as Lance has pointed out then the JDBC metadata is meant to match
the ODBC metadata, so hopefully the complete defintion of what 'length'
means in each case can be found.

> If no methods/declarations exist in Derby that can provide this info,
> then new methods/declarations are going to have to be added in order
> metadata to return the correct value.

Yes, and most likely getApproximateLengthInBytes() is not correct for
your use. I also noticed recently that the lengths returned by various
methods in the type id classes were not updated when the on-disk format
of the type changed. E.g. DATE used (several years ago) to be stored as
a serialzed java.sql.Date object, but is now a Derby specific format.

Some cleanup is probably needed in Derby's internal datatypes api to
clearly define what each get length or get size method is defined to
return. With JDBC and Derby the stored (on-disk) byte size of a type or
value is not meant to be exposed to the application. E.g. VARCHAR(10)
says that up to 10 Unicode characters can be stored in that column, not
10 bytes, or 20 bytes, but just 10 characters. Derby can then change its
storage format without affecting the application in any way.


NOTICE: If you have received this e-mail in error, please immediately notify the sender by
e-mail at the address shown.  This e-mail transmission may contain confidential information.
 This information is intended only for the use of the individual(s) or entity to whom it is
intended even if addressed incorrectly.  Please delete it from your files if you are not the
intended recipient.  Thank you for your compliance. Copyright  2005 CIGNA

View raw message