Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 20 Jul 2012 11:22:34 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <166012103.81398.1342783354911.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <631833623.81102.1342771895106.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Updated] (DERBY-5868) Move java.sql.Wrapper implementations
 to base classes on the client
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen updated DERBY-5868:
--------------------------------------

    Attachment: derby-5868-1a.patch

Attaching a patch, derby-5868-1a.patch, that moves the isWrapperFor()
and unwrap() implementations

- from Statement40, PreparedStatement40 and CallableStatement40 to Statement

- from LogicalPreparedStatement40 and LogicalCallableStatement40 to
  LogicalStatementEntity

- from ClientDataSource40, ClientConnectionPoolDataSource40 and
  ClientXADataSource40 to ClientDataSource

- from ColumnMetaData40 to ColumnMetaData

- from ParameterMetaData40 to ParameterMetaData

(The patch also moves some methods that had identical implementations in
PreparedStatement40 and CallableStatement40 to PreparedStatement.)

The above modifications allowed removal of the following classes, as they no
longer contained any methods, except constructors that forwarded their arguments
to the parent class:

- Statement40, ColumnMetaData40 and ParameterMetaData40

Because of the removals, ClientJDBCObjectFactoryImpl40 had to be adjusted to
return plain Statement, ColumnMetaData and ParameterMetaData instances instead.

Another consequence of these changes is that all the client data sources now
implement the JDBC 4.0 interface, so one doesn't have to use the data sources
whose names end with "40" to call JDBC 4.0 methods (of course, one can still use
those data sources too). I've updated the class javadoc for the data sources to
say just that.

There is a test, JDBC4FromJDBC3DataSourceTest, that tests explicitly that
calling JDBC 4.0 methods on a data source whose class name does not end with
"40", fails. This test had to be updated to not expect failure when running
against the client data sources.

I have only run the jdbc4 test suite on the patch so far. Will run the full
regression test suite on Java 5, 6 and 7.

It probably makes sense to make similar changes on the embedded side, but first
we'd need to make the JDBC 3.0 embedded interfaces compile with source level
1.5.
                
> Move java.sql.Wrapper implementations to base classes on the client
> -------------------------------------------------------------------
>
>                 Key: DERBY-5868
>                 URL: https://issues.apache.org/jira/browse/DERBY-5868
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: derby-5868-1a.patch
>
>
> The client classes that implement java.sql.Wrapper, implement the interface in the leaf classes instead of the base classes. This is because unwrap() has a generic signature, so it could not be in the base classes as long as they had to be compatible with Java 1.4.
> For example, in the statement class hierarchy, we implement unwrap() in Statement40, PreparedStatement40 and CallableStatement40. Now that we compile the client with source level 1.5, we can move the unwrap() method to the Statement class and eliminate the duplication.

--
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