db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-231) "FOR UPDATE" required for updatable result set to work
Date Fri, 04 Nov 2005 15:09:51 GMT


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.
>
>  
>

Mime
View raw message