On Thu, Sep 07, 2006 at 11:18:05AM -0700, Dean Arnold wrote:
> While we're kicking array binding around, I've got a couple
> ideas/issues to address...
>
> 1) I'm wondering about the desirability of an add'l status code
> to indicate a parameter tuple could not be sent to the server ?
> E.g., in my case, there's a limit to the size of message I can send
> to the server, so if an app binds more tuples than can be sent,
> the driver must either
>
> A) retain some state so it can pick up where the prior request
> left off (which may open the window to hell if things go wrong)
>
> B) flag the whole execution as failed (which is kindof a pain for the app)
>
> C) send as many tuples as possible, then mark the remainder as "unsent"
> and the app can then resubmit as needed, thereby alleviating the burden
> on the driver.
>
> I'll be doing (C) for DBD::Teradata using a status code of -2, but thought
> it might be generally useful to reserve a status code for that purpose ?
The default execute_array method calls execute_for_fetch. So drivers
only have to implement execute_for_fetch - and execute_for_fetch is
designed to allow drivers to decide batch sizes for themselves.
> 2) I've got a version issue: newer versions of Teradata support bulk
> operations, but older versions don't, and I need to support both. If I
> implement execute_array() in my driver, but discover the DBMS is an
> older version, how can I safely throw the call back up to the DBI
> default implementation ? (Its probably something very simple and
> obvious, but its got me stumped...)
In perl:
$h->SUPER::execute_array(...)
(but I'd recommend just implementing execute_for_fetch instead).
Tim.
