db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Wed, 01 Mar 2006 23:51:42 GMT


Daniel John Debrunner <djd@apache.org> writes:

>>> JDBC says you might see it, due to the "as the rows are retrieved".

> Here's an example of what I'm saying.

[snipped: Dan's example of sensitivity resulting from not all rows in
result set being materialized at once]

>  allows the driver to fetch rows on-demand, the "or as the rows are
> retrieved" portion, thus I believe it's valid in JDBC to allow the
> resulting fetches to only return a single row:
> 3,55.0
> thus leading to a complete scrollable ResultSet that contains:
> 1, 10.0
> 8, 76.0
> 2, 45.0
> 3, 55.0
> In this case the insensitive ResultSet did see "other changes" that
> occurred after the execution.

I agree; this is a case where the JDBC definition of sensitivity is
more lax than SQL ("no significant changes"). I am still not
convinced this applies in the updateRow case, though, which I think is
Andreas' point here.

> Another valid implementation, which is what I think Derby does today, is
> to pre-fetch all the rows, leading to a ResultSet that "satisfy the
> query at [either] the time the query is executed". Namely

Yes, it is a valid implementation (even for SQL!), but in Derby as far
as I can tell the scrollable cursors materialize incrementally as rows
are accessed. I think this is good for large result set (gets first
rows cheaper). Andreas just found a bug in that area when holdability
is true (DERBY-1058).


> 1, 10.0
> 8, 76.0
> 2, 45.0
> 7, 95.0
> 3, 45.0
> Dan.

Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101

View raw message