db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Compatibility guarantees for SQL states and messages
Date Tue, 28 Mar 2006 22:59:08 GMT
Thanks, Kathey.  What if I find an existing SQLState in the embedded 
code that uses a Derby-specific SQL State but which I think really 
should be a standard SQL state?

For example, I think 42X89 ("Types ''{0}'' and ''{1}'' are not type 
compatible. Neither type is assignable to the other type.") really is a 
case of the standard SQL State 22005 - "error in assignment"

So the question is, using the taxonomy described in

http://wiki.apache.org/db-derby/ForwardCompatibility

should SQL States be Stable or Unstable?  If they are Stable, then I 
can't fix this until 11.0, and I just need to log a bug for now.  If 
they are Unstable, I can fix this in 10.2.

I think really since our SQL States are documented, and we don't really 
think of them as "experimental" or "transitional", then they should be 
considered Stable, and I really can't change an existing SQL State in a 
minor release.

But when adding a new SQL state to the client, which takes priority: 
being consistent with the SQL state in embedded driver which is 
non-compliant with the standard, or being consistent with the SQL 
standard?  I would vote for being consistent with the standard, and 
explain that the inconsistency is due to a bug in the embedded driver 
which will be fixed in the next major release.

Thanks,

David

Kathey Marsden wrote:
> 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