Re: streaming result sets: progress

Whoa! big time over run... anyway, getting back to this:


Scott Lamb <slamb@slamb.org> writes:

> Nic Ferrier wrote:
>
> > Thomas O'Dowd  writes:
> >
> >
> > >>3) I think the transaction characteristics of the current patch are just
> > >>fine and conform to the jdbc specification.  The code should
> > >>automatically close the resultset when a commit occurs.  One thing that
> > >>will be confusing is that noncursor based result sets will work accross
> > >>commits, but cursor based ones won't.  But I think that is reasonable.
> > >
> > >Sounds reasonable to me as long as its clear to the programmer what type
> > >they are using. I definitely don't want to see the noncursor based
> > >resultsets closed, but I can't see a better solution for cursor based
> > >ones...
> >
> >
> > How can we make clear what type of ResultSet is being used?
>
> 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.


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


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


Anyone else have any opinion on this?



Nic