Re: streaming result sets: progress

Yet another sugestion :

When make createStatement, we haven't to do fetch - command is same except
begin; declare xxx cursor (I think that and begin will not be required soon)
When we call first ResultSet.next (or like) we call fetch if don't rows in memory.
It is way in another databases : execute is prepare and bind (without fetch) and then is fetch
JDBC specification tell same - execute don't nothing with row

regards
Haris Peco

On Friday 22 November 2002 03:15 pm, Nic Ferrier wrote:
> Whoa! big time over run... anyway, getting back to this:
>
> Scott Lamb <slamb(at)slamb(dot)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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster