You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2006/03/31 19:39:00 UTC
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 statement>has 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=20000
>>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=20000
>>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)
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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)
Posted by Daniel John Debrunner <dj...@apache.org>.
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)
Posted by "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)
Posted by "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
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)
Posted by 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)
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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
>
>
>
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)
Posted by Kathey Marsden <km...@sbcglobal.net>.
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)
Posted by Kathey Marsden <km...@sbcglobal.net>.
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