db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2763) In the Network Client InputStream returned using Blob.getBinaryStream() should reflect the changes made to the underlying Blob.
Date Sat, 09 Jun 2007 03:31:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502997

V.Narayanan commented on DERBY-2763:

Thank you for the comments Rick

>Issue (B) troubles me. What does it mean to read the InputStream up to position X, 
>then insert a block of bytes which straddle that position (i.e., from X-A to X+B)? 
>Quite likely, the inserted bytes have some meaning as a complete block. 
>What does it mean to read only the trailing portion of that block? 

I think this is an excellent point

As an analogy

For example if the Clob were used to store address data and it were
modified using setString, what is the point of reading from an
InputStream from this Clob which would have given the old address
initially and after the updates starts giving the new address.

>My gut feeling is that we should raise an exception if someone tries
>to write into a Blob which still has an open InputStream on it. 
>I think this should be the behavior for both the embedded and 
>network clients. 

I think we could allow updates to happen but throw an exception 
upon subsequent reads from the InputStreams after this modification 
has happened. This would not tie the writes to the LOB to the reads
from the LOB. I agree that invalidation is a form of linking the two but
the user could just re-create the stream and proceed with the reads

As in the above(address) analogy why would you proceed to read the old
data(address) when the old data(address) is no longer valid? 

Pls do mention if you think this is not the correct approach.

Thanks again for the comments Rick !!

> In the Network Client InputStream returned using Blob.getBinaryStream() should reflect
the changes made to the underlying Blob.
> -------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2763
>                 URL: https://issues.apache.org/jira/browse/DERBY-2763
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>             Fix For:
>         Attachments: LOBLengthPersists.java
> Currently the Embedded and Network Client would differ 
> in behaviour when the following series of steps is 
> followed.
> a) Create an empty Blob
> b) get an InputStream using Blob.getBinaryStream()
> c) write data into this Blob
>    c.1) Get an OutputStream
>    c.2) Use OutputStream.write(byte [] b) to write
>         into this Blob.
> d) Now read from the InputStream obtained in step b)
>    and print the number of bytes read as output.
> The output of step d) differs in the client and in the Embedded side.
> In the Client
> -------------
> The number of bytes read would always be -1.
> In the Embedded
> ---------------
> The number of bytes would be the number of bytes we
> reflected.
> The above behaviour in the NetworkClient is because
> the length of the Blob is read once and stored in the 
> constructor of the locator Stream returned (in the 
> attribute maxPos).
> This instead should be read each time we use the streams.
> A similar issue exists for Clobs also.
> I will raise a seperate JIRA issue for this.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message