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 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)
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)
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
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)
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? David Andreas Korneliussen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1172?page=all ] Andreas Korneliussen updated DERBY-1172: Attachment: DERBY-1172.diff DERBY-1172.stat The attached patch addresses the bug by catching and rethrowing. It also extends jdbcapi/HoldabilityTest.junit with two testcases which verfies that the correct exceptions is given. incorrect error message in updateRow() after a commit on a held scroll insensitive resultset Key: DERBY-1172 URL: http://issues.apache.org/jira/browse/DERBY-1172 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-1172.diff, DERBY-1172.stat If an application does updateRow() right after a commit on a held cursor, (without repositioning the cursor), an incorrect error message is given if the ResultSet is of type TYPE_SCROLL_INSENSITIVE. SQL 2003, Part 2: Foundation (SQL/Foundation) p 827, paragraph numbered 6): 6)If CR is a holdable cursor and a fetch statementhas not been issued against CR within the current SQL- transaction,then an exception condition is raised: invalid cursor state . and that exception has state 24000 Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with SQL Exception: The scan is not positioned. state: XSCH7 : code=2 If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error message: SQL Exception: Invalid cursor state - no current row. state: 24000 : code=2 The first exception is given from the store layer. The SQL layer seems to catch the store exception and rethrow a new exception with correct SQL state and error message. However this is not done in TableScanResultset.getRowLocation(), which is used by scrollinsensitve cursors. A fix could be to add this logic into TableScanResultset.getRowLocation(). Or alternatively, make the store layer throw the expected exception, and remove logic to rethrow the exception.
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 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. Another example if JDBC deprecates some method then how is that represented in the table? Dan.
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 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
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)
Kathey Marsden wrote: What do people think of adding components for Release Note Needed, Existing Application Impact and Regression ? Oops, should have made this a separate thread. I will do that some time soon unless someone else wants to start one. Kathey
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)
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.
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)
Kathey Marsden 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? 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. OK, I can add that as a note to the row for SQL States. 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 ? I think notification is great. I don't understand why what you are suggesting should be components they really seem to me to make sense as checkboxes -- how are these components of the system? Andrew, can you explain? David Kathey
