Re: streaming result sets: progress

Nic Ferrier wrote:

 > Scott Lamb  writes:
 > >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.
 >
 >
 > We don't use that "setFetchSize" we use Statement.setFetchSize.

Ahh. Didn't realize there were two. That should work, though I still
prefer specifying the required holdability because that's what defines
whether or not you're able to use the (otherwise superior) cursor method.

 > >>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.
 > [...]
 > So CLOSE_CURSORS_AT_COMMIT is not a _normal_ value for the ResultSet
 > _type_ type.

Okay, I understand now. The confusion is, you wrote this:

      Statement st = connection.createStatement(
              ResultSet.CLOSE_CURSORS_AT_COMMIT,
              ResultSet.CONCUR_READ_ONLY);

but evil gnomes changed the bits in my copy of the email to what I
expected, so I didn't notice a difference. ;) I meant this:

      Statement st = connection.createStatement(
              ResultSet.TYPE_FORWARD_ONLY,
              ResultSet.CONCUR_READ_ONLY,
              ResultSet.CLOSE_CURSORS_AT_COMMIT);

Type, concurrency, and holdability are all orthogonal parameters to
createStatement and prepareStatement.

Thanks,
Scott