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-2349) Accessing a BLOB column twice in an INSERT trigger leads to errors in the value on-disk
Date Thu, 16 Jul 2009 09:36:14 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
>            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.

View raw message