db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4214) Inconsistent metadata for CLOBGETSUBSTRING, depending on your upgrade trajectory
Date Fri, 19 Jun 2009 19:54:07 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Rick Hillegas updated DERBY-4214:

    Attachment: derby-4214-01-aa-repairMetadata.diff

Attaching derby-4214-01-aa-repairMetadata.diff. This adds 10.6 upgrade logic to fix the metadata
for SYSIBM.CLOBGETSUBSTRING. After hard-upgrade, the return type of SYSIBM.CLOBGETSUBSTRING
will be VARCHAR(10890) rather than VARCHAR(32672). Soft-upgrade does not change the signature.

The upgrade tests run cleanly for me against the 14 versions of Derby on my machine. I will
run the full regression suite.

Touches the following files:

M      java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java

Adds a method, upgradeCLOBGETSUBSTRING_10_6(), which updates the SYSALIASES tuple for SYSIBM.CLOBGETSUBSTRING.

M      java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java

Adds upgrade logic to call upgradeCLOBGETSUBSTRING_10_6() when hard-upgrading to 10.6 from
any release after 10.3. 10.3 was the release which added the SYSIBM.CLOBGETSUBSTRING function.

M      java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Version.java

Made creation of version-specific classloaders lazy. This allows us to use the version-comparing
logic of Version without faulting in unnecessary classloaders.

M      java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_6.java

Added a test to verify that the signature of SYSIBM.CLOBGETSUBSTRING is what we expect before
and after hard-upgrade. Commented-out the test for the EXPLAIN procedures since that test
raises an error right now. This error was masked by the fact that the 10.6 upgrade tests were
completely commented out.

M      java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeRun.java

Uncommented the 10.6 upgrade tests.

> 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:,,,
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-4214-01-aa-repairMetadata.diff, performance-numbers.txt
> 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 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, the signature of CLOBGETSUBSTRING will not
be the signature which you would see in a freshly created 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.

View raw message