Re: [jira] Updated: (DERBY-231) "FOR UPDATE" required for updatable result set to work

[Lance J. Andersen]

Bernt M. Johnsen wrote: Daniel John Debrunner wrote (2005-11-03 19:17:58): Thanks for the useful infomation, but how are you inferring those cursor context attributes from the JDBC ResultSet being read-only? I consider e.g. the prepareStatement/executeQuery combination to be the JDBC equivalent to the SQL/Language (ISO/IEC 9075-5) prepare statement/declare cursor combination. Thus when you in JDBC writes PreparedStatement p = c.prepareStatement("SELECT * FROM T"); ResultSet rs = p.executeQuery(); it is equivalent to PreparedStatement p = c.prepareStatement("SELECT * FROM T", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY); ResultSet rs = p.executeQuery(); which again should be equivalent something like PREPARE p FROM SELECT * FROM T FOR READ ONLY; DECLARE rs NO SCROLL CURSOR FOR p; Not all databases require a Cursor though to retrieve  and access results. BUT: Your concern about legacy is of course very important (I did not do any JDBC work prior to 2.0, and then for a database which do not support updatable cursors.) Positioned updates have been supported since JDBC 1.0.2 and the semantics behavior have not changed, even with the addition of updatable ResultSets. Anyway, I always thought that the semantic relation between the JDBC spec and the SQL standard were far to vague. Unfortunately it will be  that way in many cases ala ODBC.  While things i think continue to improve, it is hard to reach concensus and approval  given some of these databases are 20+ years old and cannot or willnot change. It is easier for new features to keep them closer in line with the SQL standard, but for older features it is not quite that easy (though it leads to interesting disccussons at the EG meetings) [...] The patch can probably proceed without this being resolved, Yes, the patch should proceed, but with a proper comment. but it would be good to come to clear agreement on if SELECT * FROM T can be updated with a positioned update/delete and a read-only ResultSet. (Even if Derby doesn't support it today, it would be nice to know or not if it is meant to be supported). It definitely would mean lower performance due to locking issues.