db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: Compatibility guarantees for SQL states and messages
Date Tue, 28 Mar 2006 23:05:53 GMT
If it is deemed to be the wrong SQLState, then you should fix it.

My experience is JDBC developers are more focused on the Exception and 
if they check further they often dig into the vendor error.  This was a 
reason we added the SQLException sub classes to help aid in better 
portability.

If you have not bought a copy of the SQL Standard you really do not know 
what this means (SQLState) anyways.

my .02

David W. Van Couvering wrote:
> 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