[
https://issues.apache.org/jira/browse/DERBY-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488082
]
Knut Anders Hatlen commented on DERBY-2540:
-------------------------------------------
This sounds like a good idea! I don't know if it's relevant for this issue, but
I think the sqlLength_ variable sometimes holds the byte count and sometimes
holds the character count for a CLOB. I don't remember the all the details, but
I once summarized what I found in this JIRA comment:
https://issues.apache.org/jira/browse/DERBY-1417#action_12424055
> 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
>
>
> 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.
