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-2495) Create framework for calling locator related stored procedures from client
Date Mon, 16 Apr 2007 12:27:15 GMT

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

Øystein Grøvlen commented on DERBY-2495:

Thanks, Kristian for committing this.  I will make a follow-up patch
that addresses your comments.  See below for responses to your

> Kristian Waagan updated DERBY-2495:
> -----------------------------------
>     Derby Info:   (was: [Patch Available])
> Committed 'blobframework_v2.diff' to trunk with revision 529185.
> Very nicely commented patch Øystein!
> I reviewed the patch and have the following suggestions/comments for a followup patch:
>  1) Would a comment that all the new set-/getX methods use 1-based
>     indexes be helpful?

I did not do this since similar existing methods did not have comments
like this, but I will add it in the follow-up patch. 

>  2) Invalid @see tag in CallableLocatorProcedures (class JavaDoc).

Will fix.

>  3) Any reason why CallableLocatorProcedures.connection isn't final?

No, and it looks like you have already made it final.  Thanks.

>  4) Can you get the value of VARCHAR_MAXWIDTH from somewhere, or use
>     an existing constant?

As far as I know, the existing constant is only available in the
embedded driver.  Do you think I ought to make the effort to make it

>     I would also make it private to signal that it is not supposed
>     to be used outside this class (I seem to recall that it is
>     defined in another class already).

Good idea.

>  5) CallableLocatorProcedures.blobTruncate could add newlines around
>     the paragraph tag.

If I understand you correctly, you want newlines both before and after
<p>. In other words, <p> should be put on a separate line?  I will
fix that.

>  6) Why use new String("") in
>     CallableLocatorProcedures.clobGetSubString?

Good point.  I guess it was because I copied the way I had done it for
blobGetBytes (return new byte[0]).  I will change it to just return "".

> The methods using repeated procedure calls for large values is a bit
> tricky, so I hope there will be some (boundary) tests in place when
> the code is enabled.

Yes, where it does not already exist, I will add test cases for
different Blob/Clob lengths in order to make sure this code is well
covered by tests.


> Create framework for calling locator related stored procedures from client
> --------------------------------------------------------------------------
>                 Key: DERBY-2495
>                 URL: https://issues.apache.org/jira/browse/DERBY-2495
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Network Client
>            Reporter: Øystein Grøvlen
>         Assigned To: Øystein Grøvlen
>             Fix For:
>         Attachments: blobframework.diff, blobframework_v2.diff, blobframework_v2.diff
> The client JDBC driver will need to call stored procedures (ref DERBY-2257) to operate
on LOBs identified by locators.  We should create a framework that implement the stored procedure
calls.  This way, the rest of the client code can call methods in this framework when needing
to call the stored procedures without having to prepare SQL statements themselves.  
> The framework should make sure that prepared statements are reused within a connection.
 Each procedure call should only be prepared once per connection.
> Since LOBs can not be parameters to stored procedures, the framework should make sure
that calls involving a byte[] or String that does not fit in a VARCHAR (FOR BIT DATA), are
split into several calls each operating on a fragment of the LOB.

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

View raw message