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