Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <8279336.1181648486109.JavaMail.jira@brutus>
Date: Tue, 12 Jun 2007 04:41:26 -0700 (PDT)
From: "Anurag Shekhar (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2712) If large clob is updated after Reader.
 the reader continues to point to old data
In-Reply-To: <11714766.1180344976585.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Anurag Shekhar updated DERBY-2712:
----------------------------------

    Attachment: derby-2712v2.diff

thanks Kristian for the review

1) Since the method EmbedClob.getInternalStream() has been added, why not rewrite the new ClobUpdateableReader constructor to only take the EmbedClob-object and fetch the stream by calling getInternalStream()?

I have modified the constroctor to take only clob.

 2) The code below can loop infinitely.
+ while (remainToSkip > 0) {
+ long skipBy = streamReader.skip(remainToSkip);
+ remainToSkip -= skipBy;
    A check to see if skipBy == 0 should be added, which if true means the EOF has been reached.
    One must consider under which scenarios this can happen (only programming error?). Would be better to fail "gracefully" instead of looping for ever.

Fixed this problem. Now I am calling read if skip returns zero. If it returns -1 it will throw EOF exception and its able to read a char it will add 1 to skipped and continue.

 3) The instance variable 'clob' in ClobUpdateableReader should be final.

fixed

 4) There are some typos in the JavaDoc. Might want to do another pass on it.
 5) Quite a few occurrences of trailing spaces.

fixed trailing spaces and typos

 6) A bit unsure about this one in ClobUpdateableReader:
+ if (clob == null) {
+ throw new IOException ("Internal error while " +
+ "updating stream");
+ }

    This can only happen if there is a programming error. Is IOException the right mechanism to communicate this?
    What about replacing it with a SanityManager.DEBUG/ASSERT?

added sanity manager.assert.


For issue 7. It will be good to remove dependency on length but as you rightly said it should be handled in a new jira.

> If large clob is updated after Reader. the reader continues to point to old data
> --------------------------------------------------------------------------------
>
>                 Key: DERBY-2712
>                 URL: https://issues.apache.org/jira/browse/DERBY-2712
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.0.0
>            Reporter: Anurag Shekhar
>            Assignee: Anurag Shekhar
>             Fix For: 10.3.0.0
>
>         Attachments: derby-2712.diff, derby-2712v2.diff
>
>
> If a Reader is fetched from a large clob (obtained from ResultSet) a reader linked to the dvd stream is returned once a set method is called on it the clob data is materialized in control class but the Reader returned previously continues to point to old data.

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