db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Compatibility guarantees for SQL states and messages
Date Tue, 28 Mar 2006 19:59:30 GMT
David W. Van Couvering wrote:

> Hi, all.  I looked at the listing of Derby's public APIs (see
> http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions
> "Derby's JDBC support".
>
> I need to delve in a little deeper.  Are we guaranteeing compatibility
> for the SQL States?  For the 10.2 release, is it OK for me to change
> the SQL State of an existing message, or do I need to keep it the same
> across minor releases?


I don't think SQLStates are defined by the JDBC Standard but rather the
SQL Standard.
To that extent they should be compliant and match embedded where possible.

SQLStates are documented but we have this caveat for client:
http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html
The following tables list /SQLStates/ for exceptions. Exceptions that
begin with an /X/ are specific to Derby. Note that some SQLStates
specific to the network client might change in future releases.

We also voted early to make client match embedded where possible and
that is in the documentation here.
http://db.apache.org/derby/docs/dev/adminguide/cadminappsclientdiffs.html.

I think that even within these guidelines early notification and buy in
from the user community is key, so should be posted on the user list.
and a Wiki page provided with information on how to write applications
that will work on both old and new versions.

But  I think it is ok to change the SQLStates on client to:
1) Match the standard.
2) Match embedded.
3)  Create a new  SQLState instead of  having a null SQLState for
SQLExceptions that are specific  to client.

but not ok to :
1) Change client from  some existing  SQLState  to another SQLState that
is neither compliant nor matches embedded.  

I think message text can be changed, but the  null SQLStates and message
text are  an interesting case, because before that was the only way for
an app to check the error. I think some of  our testing code does this.


Kathey














Mime
View raw message