Re: streaming result sets: progress

Nic Ferrier wrote:
> Scott Lamb <slamb(at)slamb(dot)org> writes:
>>I suggest with ResultSet.CLOSE_CURSORS_AT_COMMIT (cursor method) vs
>>ResultSet.HOLD_CURSORS_OVER_COMMIT (old method). You can both request a
>>certain type when you create a Statement or PreparedStatement and get
>>the type of the resultset from the Statement or PreparedStatement.
>
>
> So what you're saying is that this code:
>
> Statement st
> = connection.createStatement(ResultSet.CLOSE_CURSORS_AT_COMMIT,
> ResulSet.CONCUR_READ_ONLY);
> ResultSet rs = st.executeQuery("select * from table");
>
>
> would produce a cursor based res set whereas:
>
> Statement st = connection.createStatement();
> ResultSet rs = st.executeQuery("select * from table");
>
> would not.

Yup.

> That would mean that we didn't need the fetch size signal. Or we
> could use the fetchSize signal as well.

I'm not sure that would work anyway. It's ResultSet.setFetchSize(),
which means you must already have a resultset when to change it. So it
seems like it'd be a little late for deciding how to execute the query.

> Note also that CLOSE_CURSORS_AT_COMMIT is not actually a result set
> type so it _might_ break other code.

Not sure what you mean. If client code is using CLOSE_CURSORS_AT_COMMIT
and expecting them to work beyond commit, it's their bug and an
easily-fixed one at that. And I don't see any other negative
consequences to using cursors, just the advantage of being able to
handle large queries.

Thanks,
Scott