Tim Bunce <[EMAIL PROTECTED]> writes:
> Seeing your message has prompted me to add something I'd been meaning
> to do for a while that will simplify this somewhat:
>
> =item C<execute_for_fetch>
>
> $rv = $sth->execute_for_fetch($fetch_tuple_sub);
> $rv = $sth->execute_for_fetch($fetch_tuple_sub, [EMAIL PROTECTED]);
> So now drivers wanting to support bulk operations do not need to
> implement the full execute_array API, they just need to implement
> execute_for_fetch().
>
> For DBD::Oracle you need to setup a callback so *Oracle* will call
> the $fetch_tuple_sub code ref (via a C wrapper) to get the next row :)
Sounds great! However, after reading OCI docs a bit, I am not sure this
will work. The problem is that, as far as I can tell, OCIStmtExecute()
expects to be told the number of bind values up front; whereas if using
execute_for_fetch() as proposed, the value count is not determined until
the last callback call returns undef:
sword OCIStmtExecute (..., ub4 iters, ...)
...
iters (IN)
For non-SELECT statements, the number of times this statement is
executed is equal to iters - rowoff.
...
Did you have some particular OCI feature in mind (that I overlooked)
which would allow array execute where the count is not known in advance?
If not, two immediate options spring to mind:
1. Change the execute_for_fetch() interface, passing the count:
$rv = $sth->execute_for_fetch($count,
$fetch_tuple_sub,
[EMAIL PROTECTED]);
2. Implement execute_array() (and bind_param_array()) directly
in DBD::Oracle, to the extend possible.
What do you think?
> I don't have time to help much but if you ask me clue-full questions
> as you go along then I'll help where I can.
Thanks Tim, what you wrote was just the kind of hint I was looking
for.
- Kristian.
--
Kristian Nielsen [EMAIL PROTECTED]
Development Manager, Sifira A/S
