[
https://issues.apache.org/jira/browse/DERBY-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12731873#action_12731873
]
Kristian Waagan commented on DERBY-2349:
Investigation shows that the data is actually written incorrectly to disk. Only
the last piece (what's written on the last overflow page) is written for the
second BLOB column.
The same SQLBlob object is used as the source for both columns on input. Store
updates the stream for this dvd to be a RememberBytesInputStream. During the
insertion of the first column, this stream detects that the underlying stream
(RawToBinaryInputStream) has been exhausted, and closes itself.
When the stream is asked to fill itself for the insertion of the second column,
it only has the last piece of the previous column available.
I note that for the row trigger, the values are materialized and we don't run
into this problem. However, materializing a LOB (multiple times) is a bad idea
if it is big.
It seems we have several issues open that all have the same root cause;
reading multiple times from the same stream. The difference is the source; (a)
a user stream or (b) a Derby store stream.
(a) User stream.
In this case we don't have a choice - we have to somehow store the user stream
and then re-read the stored data. I immediately see two options, differing in
performance and possibly complexity: write the value to the temporary area and
use this as the source for further work, or write the value once to the store
and then read from store on subsequent actions.
b) Derby stream.
Since materializing the value isn't a good thing for large objects, there are
at least two remaining basic options; use of single stream with repositioning,
or cloning of streams.
There are challenges with both. For the former we have to make sure we
reposition whenever it is required, but not excessively. For the latter, we
would like to avoid cloning unless it is required.
Another thing that would be nice for large objects, is the ability to let
columns share the same field value representation. This may introduce a lot
more complex bookkeeping, it requires investigation - and for this reason it
sounds like a version 11 feature to me.
There are many things I don't know the details about in the store, so this
comment is aimed at generating feedback!
Accessing a BLOB column twice in an INSERT trigger leads to errors in the
value on-disk
---
Key: DERBY-2349
URL: https://issues.apache.org/jira/browse/DERBY-2349
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.1.4
Reporter: Daniel John Debrunner
Attachments: DERBY_2349_Repro.java
Either the BLOB is stored with the incorrect value or the value on disk does
not match the stored length on disk and an exception is raised. The BLOB was
supplied as a stream value.
See this with the new TriggersTest. The text fixture will have a comment with
this bug number showing how to reproduce the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
