Been thinking about this recently... While I still think a 'close()' semantic is needed, maybe a 'cancel()' is also needed if/when some asynch execution, or more likely multithreaded, support is implemented ?
I.e., close() means I've got a big resultset that I only want to see a few rows of, then discard the rest, so close the cursor to free up resources (client and server side). cancel() means I sent a query (potentially non-data returning) that runs much longer than I expected, so I just want to kill it, and maybe EXPLAIN my query to figure out why. Of course, in its current form, DBI doesn't really support this asynch operation short of killing the connection (true ? please edify if not...), but when threading is supported, or for drivers that implement an asynch execution mechanism, a co-thread, or some signal-initiated event, can cancel() the request. On the other hand, perhaps close() would do the same ? I guess my point of view comes from JDBC, where ResultSets/Statements have close() methods, but Statements also have cancel() methods... Regards, Dean Arnold > Can you point me to a reference that shows close() doing exactly > what finish() does? > > Tim. > > On Mon, Jul 01, 2002 at 07:28:15AM -0700, Dean Arnold wrote: > > Perhaps just $sth->close() is sufficient ? This would mimic > > most other API's syntax... > > > > Dean Arnold > > > > > > > > > > > >I'll probably rename finish() to something like > > discard_unfetched_rows(). > > > > >(Keeping an alias for old code of course.) > > > > > > > > I guess I got the idea from this sentence in perldoc DBI: > > > > > > > > The `finish' method should have been called `cancel_select'. > > > > > > I keep changing what I want to rename it to - which is why I haven't > > > renamed it yet :) > > > > > > I think discard_unfetched_rows is the most descriptive and least > > > ambiguous one I've come up with yet. > > > > > > Tim. > >
