Re: streaming result sets: progress
От | snpe |
---|---|
Тема | Re: streaming result sets: progress |
Дата | |
Msg-id | 200211221732.41579.snpe@snpe.co.yu обсуждение исходный текст |
Ответ на | Re: streaming result sets: progress (Nic Ferrier <nferrier@tapsellferrier.co.uk>) |
Список | pgsql-jdbc |
On Friday 22 November 2002 03:15 pm, Nic Ferrier wrote: > 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? > I think that if fetchSize > 0 then user cursor, if fetchSize = 0 then use old way regards Haris Peco
В списке pgsql-jdbc по дате отправления: