db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (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 13:04:26 GMT

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

Øystein Grøvlen commented on DERBY-2763:

Patch looks good.  A few comments/questions:

- 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.

- 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.

- 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?

> 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:
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>             Fix For:
>         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
> 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