db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-231) "FOR UPDATE" required for updatable result set to work
Date Wed, 02 Nov 2005 23:55:18 GMT
Bernt M. Johnsen wrote:

> The patch looks sound. I'll commit when I have run derbyall and
> experimented a bit on my own.

So the patch removes this warning

- **
- ** According to ANSI, cursors are updatable by default, unless
- ** they can't be (e.g. they contain joins).  But this would mean
- ** that we couldn't use an index on any single-table select,
- ** unless it was declared FOR READ ONLY.  This would be pretty
- ** terrible, so we are breaking the ANSI rules and making all
- ** cursors (i.e. select statements) read-only by default.
- ** Users will have to say FOR UPDATE if they want a cursor to
- ** be updatable.  Later, we may have an ANSI compatibility
- ** mode so we can pass the NIST tests.

but I can't see why it is removed. It seems that Derby will stil not
support a positioned update/delete on


whereas the comment implies according to the SQL standard it should.

I'm not saying that this change needs to improve Derby to support
positioned updates on such statements, but the code should continue to
document such limitations or variations to the standard.

Though maybe the patch does allow positioned updates on 'SELECT * FROM
T' if the JDBC result set is updateable? If that's the case, then some
additional tests should be added.

Then the change itself would seem to possibly make any future change to
supported positioned update/delete on such statements harder. This is
because the statement is made read-only by the use of a read-only JDBC
result set. As I've said before, the JDBC result set can be read-only,
and positioned updates must still work. I'm not sure if such a concern
should block the patch or not, maybe it's up to the next person who
addresses this issue to modify the code. The only concern I then have,
is there any user visible impact of this setting to read only, that
would change later?


View raw message