Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 28 Mar 2006 15:30:11 -0800
From: "David W. Van Couvering" <David.Vancouvering@Sun.COM>
Subject: Re: Compatibility guarantees for SQL states and messages
In-reply-to: <4429C151.7050408@sun.com>
To: derby-dev@db.apache.org
Message-id: <4429C703.9010103@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
References: <44288508.6060700@sun.com> <442995A2.7020705@sbcglobal.net>
 <4429BFBC.7000406@sun.com> <4429C151.7050408@sun.com>

It sounds like your vote is that the SQL States be marked Unstable, not 
Stable.

David

Lance J. Andersen wrote:
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>