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: 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)
Date Fri, 31 Mar 2006 18:08:35 GMT


Daniel John Debrunner 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.
> 
> 
> Well in this case the functionality has never been in an official
> release so I'm sure it can change.
> 
> 
>>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.
> 
> 
> I'm beginning to think that the classifications are too broad. I think
> there are some exception SQLStates that should should not change and
> some that could. In my mind it depends on if a application could be
> using the old state in a reasonable way. Very subjective of course, not
> sure if we could re-write into a more formal form.

I don't think we can.  One suggestion I received offline was to mark the 
standard SQL States as Standard and the Derby-specific SQL States as 
Unstable.  And then I think I can add a note to the SQLState column that 
changes may be permitted in some circumstances, and will be decided on a 
case-by-case basis by the community.

> 
> Another example if JDBC deprecates some method then how is that
> represented in the table?

I don't think it is.  I'm not sure if this table is intended for that 
level of detail.  Do you think it's needed?

> 
> Dan.
> 

Mime
View raw message