Re: Questions about "getApproximateLengthInBytes()"

[Daniel John Debrunner <dj...@debrunners.com>]

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.

Dan.

Re: Questions about "getApproximateLengthInBytes()"

["Lance J. Andersen" <La...@Sun.COM>]

 I raised this as a clarification issue with the EG so  that we can have 
a discussion on this.

My hope is to close on this within the next week. 

I am trying to clean-up issues like this for JDBC 4.  However, some 
issues might not get addressed until after the first EDR.  I hope to 
address as many gray areas as i can, time permitting before JDBC 4 goes 
final.



Regards
Lance

Army wrote:

> Daniel John Debrunner wrote:
>
>> 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.
>
>
> Does this mean that, until JDBC defines something further, it's okay 
> to just return the values as defined by the ODBC specification?  If 
> so, that'd certainly make my life easier (:), since ODBC nicely 
> dictates what the values are all supposed to be in the Appendix 
> mentioned by Lance:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbctransfer_octet_length.asp 
>
>
> Can I just use those values, or is that taking the expression "meant 
> to match the ODBC metadata" a bit too far?
>
>> Yes, and most likely getApproximateLengthInBytes() is not correct for
>> your use.
>
>
> Agreed.
>
>> 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.
>
>
> Is this something that should be included in the BUFFER_LENGTH patch 
> that I'm working on, or is this more of a "someone should do this 
> someday" suggestion?
>
> Thanks for the feedback,
> Army
>

Re: Questions about "getApproximateLengthInBytes()"

[Army <qo...@sbcglobal.net>]

Daniel John Debrunner wrote:

> 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.

Does this mean that, until JDBC defines something further, it's okay to just return the values as defined by the ODBC 
specification?  If so, that'd certainly make my life easier (:), since ODBC nicely dictates what the values are all 
supposed to be in the Appendix mentioned by Lance:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbctransfer_octet_length.asp

Can I just use those values, or is that taking the expression "meant to match the ODBC metadata" a bit too far?

> Yes, and most likely getApproximateLengthInBytes() is not correct for
> your use.

Agreed.

> 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.

Is this something that should be included in the BUFFER_LENGTH patch that I'm working on, or is this more of a "someone 
should do this someday" suggestion?

Thanks for the feedback,
Army