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 "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2007/07/04 17:47:04 UTC

[jira] Updated: (DERBY-1998) JDBC 4 isWrapper() and unWrap() methods allow unwrapping to Derby implementation classes.

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

Daniel John Debrunner updated DERBY-1998:
-----------------------------------------

    Priority: Major  (was: Critical)

I think there's a slight difference between these two.

EmbedStatement es = (EmbedStatement) stmt;

EmbedStatement es = stmt.unwrap(EmbedStatement.class);

The first is just how Java works.

The second is Derby's driver api indicating that the returned statement objcet is a wrapper for EmbedStatement.
That is not guaranteed by Derby either in a current release or in any future release, e.g. the object used to implement java.sql.Statement could change in the next release, even on a branch. So there is a very minor chance that an application could come to rely on it since its information obtained from Derby's driver.

I'll drop this to major, I think that some of the changes suggested are good, just relying on interfaces. 

Maybe something like

for Derby objects that implement Statement.

ireturn clazz == java.sql.Statement.class;

for Derby objects that implement PreparedStatement.

return  clazz == java.sql.Statement.class || clazz == java.sql.PreparedStatement.class

I agree it would be good to get EmbedStatement and other similar objects not to be public.


> JDBC 4 isWrapper() and unWrap() methods allow unwrapping to Derby implementation classes.
> -----------------------------------------------------------------------------------------
>
>                 Key: DERBY-1998
>                 URL: https://issues.apache.org/jira/browse/DERBY-1998
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>            Reporter: Daniel John Debrunner
>
> I do not believe that the unwrapping mechanism of JDBC 4 should allow or encourage unwrapping a JDBC 4 object as one of Derby's pribvate implementation types.
> Since Derby does *not* wrap objects in any way I would say there is a stong case for saying that the isWrapper() method should always return false and the unWrap() method always throw an exception.
> For example in EmbedStatement40 this code will allow "unwrapping" to
>    EmbedStatement40, EmbedStatement, EngineStatement, ConnectionChild, Object, Statement
>    public boolean isWrapperFor(Class<?> interfaces) throws SQLException {
>         checkStatus();
>         return interfaces.isInstance(this);
>     }
>     public <T> T unwrap(java.lang.Class<T> interfaces)
>     throws SQLException{
>         checkStatus();
>         try {
>             return interfaces.cast(this);
>         } catch (ClassCastException cce) {
>             throw newSQLException(SQLState.UNABLE_TO_UNWRAP,interfaces);
>         }
>     }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.