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] Updated: (DERBY-2763) In the Network Client InputStreams and Readers returned from LOB's should be sensitive to underlying LOB data changes.
Date Thu, 14 Jun 2007 15:06:27 GMT

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

V.Narayanan updated DERBY-2763:
-------------------------------

    Attachment: UpdateSensitiveStreamsForClient_v4.stat
                UpdateSensitiveStreamsForClient_v4.diff

- When you recreate the stream, are you getting the right length?  It
>  seems to me that if something has been read (the position has
>  changed from when creating the previous stream), the remaining
>  length should be smaller than what it was initially.

You are correct. In the cases where the subset of the stream is requested
(using getCharacterStream(long, long), getBinaryStream(long, long) the 
length has to be re-calculated as length-currentPos+1.

>- When using setBytesX, I recommend using the return value to
>  determine the number of bytes written since I do not think setBytesX
>  guarantees that everything is written (even if it always will).  I
>  guess you then would need a loop to make sure everything is written.

setBytesX internally calls the framework method blobSetBytes that has
a while loop that ensures that all the bytes are sent. Adding a loop
is redundant because it will never be called.

>- The use of -1 for unset maxPos complicates stuff a bit.  Would it
>  not be possible to set maxPos to the end of the Blob/Clob instead if
>  it was not specified?

The end of the Blob/Clob is variable. It can keep increasing with writes
and decreasing with truncates. Hence it would really not be possible to
find out if it was really a value set to represent a subset of the stream
or the end of the stream.

I have fixed the length issue in the patch attached. I have run

1) jdbcapi/BlobClob4BlobTest
2) jdbc4/BlobTest
3) jdbc4/ClobTest
4) jdbcapi/ClobUpdateableReaderTest
5) jdbcapi/BlobUpdateableStreamTest

without any failures.

I request for this patch to be considered for a commit.

> In the Network Client InputStreams and Readers returned from LOB's should be sensitive
to underlying LOB data changes.
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2763
>                 URL: https://issues.apache.org/jira/browse/DERBY-2763
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.3.0.0
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>             Fix For: 10.3.0.0
>
>         Attachments: Approach_2.diff, Approach_2.stat, Approach_2.txt, Approach_3.diff,
Approach_3.stat, Approach_4.diff, Approach_4.stat, LOBLengthPersists.java, UpdateSensitiveStreamsForClient_v1.diff,
UpdateSensitiveStreamsForClient_v1.stat, UpdateSensitiveStreamsForClient_v2.diff, UpdateSensitiveStreamsForClient_v2.stat,
UpdateSensitiveStreamsForClient_v3.diff, UpdateSensitiveStreamsForClient_v3.stat, UpdateSensitiveStreamsForClient_v4.diff,
UpdateSensitiveStreamsForClient_v4.stat
>
>
> 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.


Mime
View raw message