db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
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 17:56:41 GMT
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?

 I think it is ok and good to change an SQLState or any behaviour  to
fix a bug if our current behaviour is non-standard.
The question becomes what level of notification do we need to users and
what strategy will we give them to  mitigate the impact of the change?

In this case,  I think  this is  new functionality,  so all very good it
is caught now and dealt with.   If it were existing functionality, I
think that  user notification would be very important.  I think we need
some way of  marking changes that might affect existing users.  I made
this proposal a while back for Jira that I think would help:

http://www.nabble.com/New-Jira-Checkbox-proposal-t1200029.html#a3166517

Feedback from Andrew indicated that components  are preferred to
checkboxes but being able to query Jira for changes that might affect
users I think is important.  What do people think of adding components
for "Release Note Needed", "Existing Application Impact"  and "Regression" ?


Kathey




Mime
View raw message