The DBI already has a cancel method. Not many drivers do though. Tim.
On Tue, Jul 09, 2002 at 10:56:58PM -0700, Dean Arnold wrote: > 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. > > > >
