[
https://issues.apache.org/jira/browse/DERBY-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706350#action_12706350
]
Kristian Waagan commented on DERBY-4214:
----------------------------------------
Rick wrote:
-----
1) If you upgrade a database to 10.5.1.1, the signature of CLOBGETSUBSTRING
will not be the signature which you would see in a freshly created 10.5.1.1
database. Presumably this means that the problem addressed by DERBY-3769 is not
solved in upgraded databases.
----
The effect of this depends on the data stored in the Clob and the way the Clob
is fetched with the client driver;
o If the client asks for chunks of 10890 characters or less in the read loop,
the performance will be identical.
o If more than 10890 characters are requested *and* the Clob contains
characters that require two or three bytes to be encoded in UTF-8, performance
will be significantly worse for larger Clobs without DERBY-3769.
In the worst case, Derby will appear to have hung and the server will eat
up all the CPU.
o If more than 10890 characters, but less than or equal to 32760, are
requested and the Clob contains only one-byte UTF-8 encoded characters, the
user will see better performance without DERBY-3769 (less roundtrips).
Because the potential loss of performance is significantly higher than the
potential gain, I chose to assume multi-byte characters and reduce the number
of characters transferred in one go.
DERBY-3918 has been logged to improve the implementation.
The user can work around this issue by choosing one of the streaming methods to
fetch the Clob *and* adjust the read buffer accordingly, or use
Clob.getSubString() to fetch small pieces (<= 10890).
> Inconsistent metadata for CLOBGETSUBSTRING, depending on your upgrade
> trajectory
> --------------------------------------------------------------------------------
>
> Key: DERBY-4214
> URL: https://issues.apache.org/jira/browse/DERBY-4214
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.4.3.0, 10.5.1.1, 10.5.1.2, 10.6.0.0
> Reporter: Rick Hillegas
>
> The on-disk signature of CLOBGETSUBSTRING changed as a result of the work
> done on DERBY-3769. Previously, the return type of that function was
> VARCHAR(32672). The return type changed to VARCHAR(10890) with revision
> 707097, which made it into release 10.5.1.1. That change was also backported
> to the 10.4 branch at 711548. However, no upgrade logic was written to
> support this metadata change. As a result, we have two discrepancies with our
> upgrade policy:
> 1) If you upgrade a database to 10.5.1.1, the signature of CLOBGETSUBSTRING
> will not be the signature which you would see in a freshly created 10.5.1.1
> database. Presumably this means that the problem addressed by DERBY-3769 is
> not solved in upgraded databases.
> 2) If we create another release on the 10.4 branch, then we will have a
> change in on-disk metadata introduced by a bug-fix release.
> I see two solutions:
> A) Add metadata upgrade logic to the 10.4 and 10.5 branches so that
> DERBY-3769 will be fixed in upgraded databases as well as freshly created
> databases. This will violate our policy of not changing on-disk metadata in
> maintenance releases.
> B) Correct the metadata in the hard-upgrade logic of 10.6. We may want to
> revert the 10.4 backport.
> In any event, we may also want to re-open DERBY-3769 to indicate that the bug
> is not fixed in hard-upgraded databases but only in freshly created databases.
> What are people's thoughts about how to address this discrepancy?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
