Tim Bunce wrote:
On Thu, Sep 07, 2006 at 04:06:05PM -0700, Dean Arnold wrote:
Tim Bunce wrote:
However, that still leaves open the issue of unsent tuples, e.g.,
a connection failure occurs after 10,000 tuples are sent and
committed, and 10,000 tuples remain. How do we inform the app
of the unsent tuples (for recovery purposes) ? (Which is one
use of the suggested -2 status code).
The tuple status array just wouldn't have entries beyond the last tuple
sent - they'd effectively be undef.
I realized that today while implementing. I've been treating
the provided tuple_status as 'immutable', ie, not being able to trim
it...but that doesn't make sense, since I am certainly expanding
it if (scalar @$tuple_status < $rows_sent). So I can just trim the
tuple status down to only rows sent.
Using the above scenario,
the DBD would just keep consuming tuples and marking their status
as -2 (which might be a rather lengthy process unless the app limits
itself to reasonable chunks of tuples per execute_array() call).
E.g., since the default DBI exec_for_fetch() doesn't have a way
to bust out of its loop until all tuples are consumed, the
default execute() return code may pile up a lot of error msgs
to the effect "No connection available" (short of some HandleError
closure, I guess ?).
There's no reason execute_for_fetch can't return early if there's been
an error that means it can't continue.
OK, thats good to hear, my reading of the default code led me to think
otherwise.
Thnx,
Dean
