db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Wed, 01 Mar 2006 00:58:58 GMT
Øystein Grøvlen wrote:

> Daniel John Debrunner (JIRA) wrote:
>> Agreed, it's the same issue in my mind, and allowing such a row in a
>> ResultSet would be wrong. I believe after an update the row in the
>> ResultSet must reflect the state of the row in the database. Hence,
>> like Oracle, Derby should perform the equivalent of a refreshRow.
> I think such an implementation kind of blurs the concept of sensitivity.
>   You get a result set that is sensitive to some, but not all, changes
> performed by other statements in the same transaction.  The available
> metadata for a result set, does not provide a way to describe such
> behavior. 

Not sure I agree, I think insensitive result sets are like that anyway.
Taking this from the spec, that Dag quoted:

> - JDBC 3.0 spec: "The result set is insensitive to changes made to the
> underlying data source while it is open. It contains the rows that
> satisfy the query at either the time the query is executed or as the
> rows are retrieved." 

Since a row value can be from the time the query was executed or as the
rows are retrieved, I can have a ResultSet where some rows show the
effect of a statement, while other rows do not show the effect of the
same statement. Not sure an implicit refreshRow() after an updateRow()
makes the situation any different.

> This whole discussion makes me think that the only sensible
> way to implement an insensitive result set is to not make own changes
> visible.  At least, that would give a clean implementation with a
> behavior that is easy to understand.

That's one clean option.


View raw message