You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2012/07/20 10:11:35 UTC
[jira] [Created] (DERBY-5868) Move java.sql.Wrapper implementations
to base classes on the client
Knut Anders Hatlen created DERBY-5868:
-----------------------------------------
Summary: 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
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
[jira] [Updated] (DERBY-5868) Move java.sql.Wrapper implementations
to base classes on the client
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (DERBY-5868) Move java.sql.Wrapper implementations
to base classes on the client
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-5868:
--------------------------------------
Issue & fix info: Patch Available
Derbyall and suites.All passed on Java 5, 6 and 7 with the patch.
> 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
[jira] [Resolved] (DERBY-5868) Move java.sql.Wrapper
implementations to base classes on the client
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-5868.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.10.0.0
Issue & fix info: (was: Patch Available)
Committed revision 1364042.
> 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
> Fix For: 10.10.0.0
>
> 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