db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4214) Inconsistent metadata for CLOBGETSUBSTRING, depending on your upgrade trajectory
Date Wed, 06 May 2009 08:49:30 GMT

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


Mime
View raw message