db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2540) Restructure code for Blob/Clob length in client to prepare for locator implementation
Date Thu, 12 Apr 2007 09:08:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488308

Øystein Grøvlen commented on DERBY-2540:

Knut Anders, thanks for the reference to your summary of length
issues.  For this patch I do not intend to change any behavior here.

However, I will propose to remove Clob.getByteLength() and its
associated field.  The method is not used by any Derby code and it is,
as far as I can tell, not working correctly.  In your summary, you
write that getByteLength() gives the same result as length().  This is
initially true, but if the length of the Clob is changed (e.g., by
truncate()), getByteLength() will still return the original value.
In addition, I do not understand how this associated comment applies to
the current implementation:

    // this method is primarily for mixed clob length calculations.
    // it was introduced to prevent recursion in the actual char
    // length calculation

Given all this, I think it is better to just remove it.

> Restructure code for Blob/Clob length in client to prepare for locator implementation
> -------------------------------------------------------------------------------------
>                 Key: DERBY-2540
>                 URL: https://issues.apache.org/jira/browse/DERBY-2540
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Network Client
>            Reporter: Øystein Grøvlen
>         Assigned To: Øystein Grøvlen
>             Fix For:
> In order to prepare for the locator-based implementation, I want to restructure the code
for getting the length of LOBs. 
> Currently, the LOB class has a protected field sqlLength_ that will contain the length
of the LOB, if known.  Currently, it is always known as long as the LOB has been materialized.
 However, when locators are introduced, the length may have to be fetched from the server
the first time it is needed.   With the current implementation, where sqlLength_ is accessed
directly by many classes in the package, it will become very difficult to keep track of whether
one needs to fetch the length from the server or not.
> I will change the implementation to make Lob.sqlLength_ private and add access methods
to get and set its value.  (A good thing in itself IMHO).  If the length is unknown, the LOB
will be materialized to get the length. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message