Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 11 Apr 2011 14:50:05 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1666812782.49200.1302533405795.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-4544) Referencing streaming CLOBs in (some)
 generated column clauses fails
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rick Hillegas updated DERBY-4544:
---------------------------------

    Attachment: derby-4544-01-ab-shortCircuitLengthOptimization.diff

Attaching derby-4544-01-ab-shortCircuitLengthOptimization.diff. This patch makes the repro behave correctly. I will run regression tests. More tests need to be written to verify that other generation expressions work on streaming Clobs.

The SQLClob.getLength() method is a little tricky. It ends up calling getStreamWithDescriptor(). That method has a prominent comment saying that it doesn't expect to be called more than once--which happens if your generation clause invokes the length() function on a streaming Clob.

There is no SQLBlob.getLength() method. Instead, if you call the length() function on a streaming Blob, you will get the getLength() behavior of the superclass, which materializes the Blob.

The fix is to make SQLClob.getLength() first check whether it is operating on a non-resetable stream. If the stream is not resetable, then the assumptions of getStreamWithDescriptor() will be violated. For non-resetable streams, SQLClob.getLength() will just do what Blobs do, i.e., defer to the getLength() method in the superclass which materializes the Clob.

This will be inefficient--but that is better than causing a data corruption.


Touches the following files:

----------------

M      java/engine/org/apache/derby/iapi/types/SQLClob.java

1 line fix to force materialization if getLength() is called on a non-resetable stream.

----------------

A      java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DummyReader.java
M      java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ClobTest.java

Test case demonstrating the fix.


> Referencing streaming CLOBs in (some) generated column clauses fails
> --------------------------------------------------------------------
>
>                 Key: DERBY-4544
>                 URL: https://issues.apache.org/jira/browse/DERBY-4544
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.3.0, 10.6.1.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>              Labels: CLOB, derby_triage10_8
>         Attachments: Test_4544.java, Test_4544.java, derby-4544-01-ab-shortCircuitLengthOptimization.diff
>
>
> Referencing a CLOB represented as a stream in generated columns can lead to data corruption or that the query fails.
> For instance, with 10.5:
> create table t (id int, myclob clob, clen generated always as (length(myclob)));
> # Insert CLOB using the streaming APIs (setCharacterStream).
> The exception 'java.lang.ClassCastException: org.apache.derby.iapi.types.ReaderToUTF8Stream cannot be cast to org.apache.derby.iapi.types.Resetable'
> On trunk the same query results in data corruption, and this isn't detected before the value is read back from store.
> Workaround:
> Don't use the streaming APIs when using CLOBs in generated columns. This increases the memory footprint, and may not feasible for large CLOBs.
> FYI, BLOB deals with this by materializing the value, which effectively equals to using the workaround mentioned above.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira