db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Questions about "getApproximateLengthInBytes()"
Date Mon, 04 Apr 2005 22:36:44 GMT
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, is
> it okay to use that for the metadata calls?  And on that premise, I was
> 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 for
> 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.


View raw message