db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-819) Provide JDBC4 SQLException subclasses support in Embedded driver
Date Thu, 23 Feb 2006 23:21:38 GMT
    [ http://issues.apache.org/jira/browse/DERBY-819?page=comments#action_12367599 ] 

Rick Hillegas commented on DERBY-819:

It appears to me that 2 of the BLOCKER issues have been addressed:

1) The startup NPE has been fixed by a static intializer, as recommended.
2) The test code now checks for expected SQLStates.

I can't evaluate the remaining BLOCKER issue (cruft in SystemProcedures.java) because I don't
find that class in either the current patch (derby-819_3.diff) or the previous patch (derby-819_2.diff).
Moving the factory methods back to Utils really cleaned up the patch. Lots of good work on
copyright notices and comments.

I don't see the following issue addressed: Dan wanted to see a comment in the code explaining
what functionality is lost by using the JDBC exception classes for JDBC4 rather than EmbedSQLException
(which is used for JDBC3). Dan is not objecting to this change, he just wants to understand
whether we need to compensate for this lost functionality some other way.

Anurag, could you explain the SystemProcedures.java issue to me?  Could you add a comment
explaining what we've lost by migrating from EmbedSQLException to the JDBC4 exception classes?

> Provide JDBC4 SQLException subclasses support in Embedded driver
> ----------------------------------------------------------------
>          Key: DERBY-819
>          URL: http://issues.apache.org/jira/browse/DERBY-819
>      Project: Derby
>         Type: Sub-task
>   Components: JDBC
>  Environment: all
>     Reporter: Anurag Shekhar
>     Assignee: Anurag Shekhar
>     Priority: Minor
>  Attachments: .derby-819_2.stat, derby-819-onlyforreview.diff, derby-819.diff, derby-819_2.diff,
derby-819_3.diff, stat.out

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message