[
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
comments.
> 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
shared?
> 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.
--
Øystein
> 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: 10.3.0.0
>
> 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.
