Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

[Andreas Korneliussen <An...@Sun.COM>]

David W. Van Couvering wrote:
> This is an example where we find our code throwing the wrong SQL State, 
> but are we allowed to fix it?  Lance says yes.  Others providing support 
> for customers say (I think) no.
> 
> This ties into the discussion about the stability classification for SQL 
> States.  If we mark it as Stable, then we can't change this.  If we mark 
> it as Unstable, then we can.
> 
> Comments, thoughts?
> 
Is there a document for Derby with error conditions and expected SQL 
state ? If there is no such document, one cannot claim that the 
classification for SQL state is Stable.

In general, I do not think any interface can be marked as stable, unless 
documented.

Even if we do have a document of expected error conditions and expected 
SQL state, we should be allowed to make bugfixes if the implementation 
is incorrect w.r.t the document / specification.

Andreas

Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

["David W. Van Couvering" <Da...@Sun.COM>]

I reviewed such a document that was contributed by Jeff Levitt as part 
of 10.1, see http://db.apache.org/derby/docs/10.1/ref/rrefexcept71493.html

In my latest ref of the interface table, I have marked those SQL States 
that are based on the SQL Standard as Standard, and those SQL States 
that are specific to Derby as Unstable.

David

Andreas Korneliussen wrote:
> David W. Van Couvering wrote:
> 
>> This is an example where we find our code throwing the wrong SQL 
>> State, but are we allowed to fix it?  Lance says yes.  Others 
>> providing support for customers say (I think) no.
>>
>> This ties into the discussion about the stability classification for 
>> SQL States.  If we mark it as Stable, then we can't change this.  If 
>> we mark it as Unstable, then we can.
>>
>> Comments, thoughts?
>>
> Is there a document for Derby with error conditions and expected SQL 
> state ? If there is no such document, one cannot claim that the 
> classification for SQL state is Stable.
> 
> In general, I do not think any interface can be marked as stable, unless 
> documented.
> 
> Even if we do have a document of expected error conditions and expected 
> SQL state, we should be allowed to make bugfixes if the implementation 
> is incorrect w.r.t the document / specification.
> 
> Andreas

Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

["David W. Van Couvering" <Da...@Sun.COM>]

And, yes, I think we have generally agreed it's OK to fix a bug if Derby 
is incorrect in terms of data returned or compliance with standards. 
See the Exceptions section of the ForwardCompatibility page.  Note this 
hasn't been voted on yet, but that seems to be the direction we're heading.

David

Andreas Korneliussen wrote:
> David W. Van Couvering wrote:
> 
>> This is an example where we find our code throwing the wrong SQL 
>> State, but are we allowed to fix it?  Lance says yes.  Others 
>> providing support for customers say (I think) no.
>>
>> This ties into the discussion about the stability classification for 
>> SQL States.  If we mark it as Stable, then we can't change this.  If 
>> we mark it as Unstable, then we can.
>>
>> Comments, thoughts?
>>
> Is there a document for Derby with error conditions and expected SQL 
> state ? If there is no such document, one cannot claim that the 
> classification for SQL state is Stable.
> 
> In general, I do not think any interface can be marked as stable, unless 
> documented.
> 
> Even if we do have a document of expected error conditions and expected 
> SQL state, we should be allowed to make bugfixes if the implementation 
> is incorrect w.r.t the document / specification.
> 
> Andreas