db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1059) call to stored procedure with out params fails in embedded driver
Date Fri, 10 Mar 2006 15:03:41 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1059?page=comments#action_12369868 ] 

Daniel John Debrunner commented on DERBY-1059:
----------------------------------------------

The existing code uses the inheritence model, which has lead to a small number of duplicated
methods.
Usually  these duplicated methods are very simple, so compilcated logic is not

I think it would be wise to havea single model for the set of embedded jdbc prepared statement/callable
statement
classes, rather than two models.

I don't know if it helps here, but traditionally we have pushed any new methods added in a
new JDBC version
as far up the tree as possible. If there are no requirements on new JDBC 4.0/JSE 6 classes,
then it's fine
for a JDBC 4.0 method to be in the base EmbePreparedStatement class.

> call to stored procedure with out params fails in embedded driver
> -----------------------------------------------------------------
>
>          Key: DERBY-1059
>          URL: http://issues.apache.org/jira/browse/DERBY-1059
>      Project: Derby
>         Type: Sub-task
>   Components: JDBC
>     Versions: 10.2.0.0
>     Reporter: Anurag Shekhar
>     Assignee: Anurag Shekhar
>  Attachments: derby-1059.diff, derby-1059_2.diff
>
> org.apache.derby.impl.jdbc.EmbeddedCallableStatement40 and org.apache.derby.client.am.CallableStatement40
are instantiating Preparewdstament in 
> constructor. Becasue of this call to stored procedure with out param fails.
> Instantiatiation of prepared was done to share the common method in prepared statement
and callbale statement. But this aporach causes another issue of creating two instance of
statement (one by calling super () and another by instantiating prepared statement). 
> I can think of two solution of this problem 
> 1. Create another class which handles the common methods in PrepardStatement40 and CallableStatement40
classes.
> 2. Duplicate the common method in both classes. 
> I feel 1st one is better. It will will be easier to fix any issue in the common methods
and chance to miss to fix in one of the classes will be eliminated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message