Henri Asseily <[EMAIL PROTECTED]> wrote:
> The problem is not to know when a request is done processing.
> The problem is killing requests that are processing for too long.
> If you want kill them safely, you may not be able to kill them until
> they're done, which defeats the purpose.
> If you k
On Mon, Sep 18, 2006 at 09:22:28AM +0100, Martin J. Evans wrote:
> Tim,
>
> I see you've "tweaked" the pod changes I made for the new execute_array
> in array context so it now says -1 is returned as the rows affected if
> the driver can't return the rows affected.
>
> I think the change to DBI's
On Sep 18, 2006, at 6:18 PM, Tyler MacDonald wrote:
Dean Arnold <[EMAIL PROTECTED]> wrote:
Which brings me back to the notion of non-blocking requests.
Assuming
many/most client libs do support an async capability, and a OOB
cancel, then it should be possible to standardize the behavior
exte
Dean Arnold <[EMAIL PROTECTED]> wrote:
> >>Which brings me back to the notion of non-blocking requests. Assuming
> >>many/most client libs do support an async capability, and a OOB
> >>cancel, then it should be possible to standardize the behavior
> >>externally.
> >
> >Attempting to standardize,
For your reference:
sub dump_results { # also aliased as a method in DBD::_::st
my ($sth, $maxlen, $lsep, $fsep, $fh) = @_;
return 0 unless $sth;
$maxlen ||= 35;
$lsep ||= "\n";
$fh ||= \*STDOUT;
my $rows = 0;
my $ref;
while($ref = $sth->fetch) {
print $fh $ls
Tim Bunce wrote:
Which brings me back to the notion of non-blocking requests. Assuming
many/most client libs do support an async capability, and a OOB
cancel, then it should be possible to standardize the behavior
externally.
Attempting to standardize, let alone implement, non-blocking reque
On Sun, Sep 17, 2006 at 10:59:48AM -0700, Dean Arnold wrote:
> (I've added dbi-dev as this seems relevant)
>
> Tim Bunce wrote:
> >On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
> >>On Sat, 16 Sep 2006, Dean Arnold wrote:
> >>
> >>>I think your best bet might be to work with the DBD::
Tim,
I see you've "tweaked" the pod changes I made for the new execute_array
in array context so it now says -1 is returned as the rows affected if
the driver can't return the rows affected.
I think the change to DBI's execute_for_fetch for drivers not
implementing execute_for_fetch contains some
