db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5877) Prune the brokered class tree
Date Tue, 24 Jul 2012 07:34:37 GMT

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

Knut Anders Hatlen updated DERBY-5877:
--------------------------------------

    Attachment: d5877-1a.diff

The attached patch makes the following changes to the brokered class tree:

1) Moved the JDBC 3.0 methods from BrokeredPreparedStatement30 to BrokeredPreparedStatement,
to enable reuse of them in BrokeredCallableStatement30.

2) Removed the JDBC 3.0 PreparedStatement methods from BrokeredCallableStatement30, since
they're now inherited from BrokeredPreparedStatement.

3) Moved the JDBC 3.0 CallableStatement methods from BrokeredCallableStatement30 to BrokeredCallableStatement.

4) Moved the JDBC 3.0 methods from BrokeredConnection30 to BrokeredConnection.

5) Removed the now empty BrokeredConnection30, BrokeredPreparedStatement30 and BrokeredCallableStatement30
classes, and made Driver30.newBrokeredConnection() return a BrokeredConnection instance instead
of a BrokeredConnection30 instance.

All the regression tests ran cleanly with the patch.
                
> Prune the brokered class tree
> -----------------------------
>
>                 Key: DERBY-5877
>                 URL: https://issues.apache.org/jira/browse/DERBY-5877
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d5877-1a.diff
>
>
> The brokered class tree still separates between the JDBC 2.0 functionality and JDBC 3.0.
This leads to unnecessarily many levels of classes (for example, BrokeredPreparedStatement
-> BrokeredPreparedStatement30 -> BrokeredStatement40). Another consequence is that
BrokeredCallableStatement30 and BrokeredPreparedStatement30 don't have a common base class
that could hold shared JDBC 3.0 methods (their common base class is BrokeredPreparedStatement,
which is JDBC 2.0), and therefore new JDBC 3.0 PreparedStatement methods are duplicated in
the two classes.
> We should fold the JDBC 3.0 classes into the JDBC 2.0 classes so that we can reduce the
number of classes and the duplication of code in the brokered statement sub-tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message