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-4544) Referencing streaming CLOBs in (some) generated column clauses fails
Date Mon, 11 Apr 2011 14:50:05 GMT

     [ 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

Mime
View raw message