Ooops...upon reflection, I realize that any parameters
supplied directly in execute()/execute_array() are assumed to have
"default" (eg VARCHAR) type, so a number of my issues below
aren't relevant.
However, IMHO, that still leaves a hole in the 'ArrayTupleFetch => sub { }'
approach if type info is desired, as well as for any alternate rowwise binding...
unless (as previously mentioned) individual "dummy" bind_param()'s
are used to supply type info for each tuple element.
Perhaps just a new binding i/f is needed, eg,
bind_tuple_array([ [ tuple1], [tuple2], ... [tupleN] ], [EMAIL PROTECTED]);
and execute_array() just automagically recognizes that tuples were bound
rowwise ? That may require some add'l DBD driver i/f (as Kristian has
described), but perhaps it simplifies the app level code ?
(Not certain what the behavior is if a misguided app writer
mixes columnwise and rowwise bindings...probably an error ?)
Dean Arnold
Presicient Corp.
www.presicient.com
----- Original Message -----
From: "Dean Arnold" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Kristian Nielsen" <[EMAIL PROTECTED]>
Sent: Wednesday, October 08, 2003 1:43 PM
Subject: Re: DBD::Oracle and bulk binds via execute_array
> <snip>
> >
> > So here is my suggestion, based on my work on the DBD::Oracle
> > execute_array patch:
> >
> > DBI interface:
> >
> > The main user-level interface is execute_array(). Four different ways to
> > use:
> >
> > 1. Column-wise, using $sth->bind_param_array() for each column, then
> > $sth->execute_array(\%attr). This is the only method that supports
> > named placeholders (:foo style).
> > 2. Column-wise, using $sth->execute_array(\%attr, [EMAIL PROTECTED], [EMAIL
> > PROTECTED]).
>
> m'kay.
>
> > 3. Row-wise, using execute_array({ArrayTupleFetch => sub { ... } }).
> > This is the only row-wise method supported in DBI 1.37. This permits
> > calling execute_array() with a very large number of rows without
> > having to keep them all in memory at once (subject to driver support;
> > Oracle will buffer rows and send them off to Oracle in batches
> > because of OCI restrictions).
>
> Does this need to be modified to provide the column type info ? I don't see
> anything in the DBI 1.38 POD indicating type info can be specified...tho
> I spose the bind_param() i/f (wo binding data) can be used as a cheat ?
>
> > 4. Row-wise, using execute_array({ArrayTuple => [ [1,'A'], [2,'B'] ]}).
> > Useful in the common case where the user already has a list
> > of tuples. Less memory-efficient than column-wise, though.
>
> Again, whence column type info ? Also, why less memory efficient
> (in the wholistic sense) ? If you bind N column arrays of M elements each
> column wise, vs. binding M tuple arrays of N columns for rowwise,
> isn't the total memory use nearly equal ?
>
> >
> > DBD::xxx interface:
> >
> > Low-level methods implemented by drivers and usually only called by the
> > DBI implementation of execute_array():
> >
> > 1. The execute_for_fetch() method. The implementation of this in the
> > driver is mandatory (in the sense that without it no native
> > execute_array() will be available; DBI will emulate it with an
> > execute() for each row).
>
> I assume you mean mandatory to support rowwise ?
>
> > 2. A new $sth->execute_array_rowwise([EMAIL PROTECTED], [EMAIL PROTECTED])
> > for direct implementation of row-wise array execution. Optional; if
> > implemented it will be used by DBI::execute_array() when an array of
> > tuples is already available (ie. execute_array() method 4 above).
>
> - needs type attribute capability; maybe also a named PH order list to indicate
> which tuple elements map to which named PHs ?
>
> - should argument order be changed to more closely match execute_array ?
>
> > 3. A new $sth->execute_array_colwise([EMAIL PROTECTED], [EMAIL PROTECTED], ...,
> > [EMAIL PROTECTED])
> > for direct implementation of column-wise array execution. Optional;
> > if implemented it will be used by DBI for execute_array() method 1
> > and 2 above. If we want to implement named placeholders this method
> > needs to be extended to take a mapping { 'foo' => [EMAIL PROTECTED],
> > 'bar' => [EMAIL PROTECTED] }, but maybe that is not so important.
> >
> >
> > - Kristian.
> >
> > --
> > Kristian Nielsen [EMAIL PROTECTED]
> > Development Manager, Sifira A/S
> >
>
> Dean Arnold
> Presicient Corp.
> www.presicient.com
>
