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

Dag H. Wanvik commented on DERBY-2540:
--------------------------------------

Thanks, Øystein!
I ran the regression tests over again cleanly with JDK1.6.

Committed at svn 530070.

> 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: 10.3.0.0
>
>         Attachments: derby-2540.diff, derby-2540.stat, derby-2540_2.diff
>
>
> 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.

Reply via email to