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] Updated: (DERBY-2495) Create framework for calling locator related stored procedures from client
Date Fri, 30 Mar 2007 13:30:25 GMT

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

Øystein Grøvlen updated DERBY-2495:

    Attachment: blobframework.diff

The patch blobframework.diff adds a class CallableLocatorProcedures
that provides methods for calling the stored procedures used to
operate on LOBs identified by locators.  There will be one instance of
this class for each connection that has called any of the stored
procedures.  For each procedure that has been called, a reference is
kept to the CallableStatement object so that a call needs to be
prepared once per connection.

If the byte[] and String parameters and return values for the methods
exceed the maximum size for such in stored procedure (i.e. the
maximum size for VARCHAR), repeated calls to the stored procedures
will be done to transfer the data to the server.

NOTE: The use of locators are still not enabled so most of this code
when checked in, will not be executed.  (The changes to
PreparedStatement and CallableStatement will have effect.  However,
these changes only extract existing code into a separate method.) When
DERBY-2496 is ready, locators will be enabled for Blobs.

The patch changes the following files:

M      java/client/org/apache/derby/client/am/Connection.java

   - Adds a method that is to be used to get a reference to the
     CallableLocatorProcedures object for this Connection.  The object
     is created on the first invocation of this method.

   - Made prepareCallX package private so that it can be used by
     CallableLocatorProcedures to prepare the procedure calls.

M      java/client/org/apache/derby/client/am/PreparedStatement.java

   - Added setLongX() similar to the existing setIntX().  Used by
     CallableLocatorProcedures and avoid the unecessary parameter
     testing and exception mismatch of setLong()

M      java/client/org/apache/derby/client/am/CallableStatement.java

   - Added getLongX() and getBytesX() for the same reasons as given

A      java/client/org/apache/derby/client/am/CallableLocatorProcedures.java

   - The above mention class which is used by callers of the stored
     procedures for locators.  The Blob methods of this class has been
     tested by code that I am currently working on for DERBY-2496.
     The Clob methods have not yet been tested, but the code is very
     similar to the Blob methods.

I am currently running the JUnit suit and derbyall for this patch, and
will get back to you with the results.  However, I do not expect to
see any problems since 97% of this code has not been enabled, and the
rest are very simple changes.  (I have also run these changes together
with other changes without seeing any problems.)

> 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
>            Reporter: Øystein Grøvlen
>         Assigned To: Øystein Grøvlen
>             Fix For:
>         Attachments: blobframework.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