You might want to view the dbi-dev maillist, we've been kicking around
solutions to this. The last proposal was bind_param_array()
and bind_col_array() methods,
and associated bind_param_status() and bind_row_status() for
reporting individual tuple status info.
I have hacked up DBD::ODBC and the DBI layer to support these -with pretty
good performance improvement for DB2 (up to 20x faster) and Oracle (up to 10x
faster). I have turned this over to the keeper of DBD::ODBC, and (hopefully)
it will be incorporated into the next release.
As for your suggestions, I think the caching of rows may have some
problems wrt transaction behavior, and also making inter-object calls for each
row would detract from the performance improvement (as opposed to passing
arrays in a single inter-object call). Also, the bind_param_array() API permits
mixing arrays and scalars in a single statement execution
(e.g., for stored procedure parameters).
Regards,
Dean Arnold
----- Original Message -----
From: "Jeff Holt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, February 28, 2001 4:43 AM
Subject: Potential DBI array insert solution
> I respectfully request feedback for the following potential DBI array
> insert solution.
>
> PART 1
> Add two new hash array attributes for the connect() and prepare()
> methods called 'insertcount' and 'insertsize'. The 'insertcount'
> attribute tells the execute() method to 'cache' a number of rows before
> performing an array insert. The 'insertsize' attribute tells the
> execute() method to not exceed the specified 'cache' size. The
> 'insertsize' attribute should override the 'insertcount' attribute. If
> these two attributes aren't set then, for backwards compatibility, the
> existing DBI v1.14 behavior should prevail (the default for
> 'insertcount' should be 1). If the statement being prepared is not an
> insert and the attributes were set via:
> . connect(), then they should be ignored
> . prepare(), then an error should be raised
>
> PART 2
> Add a new method called execflush() that allows the programmer to
> control the DBI's behavior on commit or disconnect. One could possibly
> argue that
> the DBI could 'sense' pending rows prior to a commit or disconnect.
>
> Thanks,
>
> --
> Jeff Holt
> Chief Scientist, Hotsos LLC
> mailto:[EMAIL PROTECTED]
> +1.817.821.9553 tel
> +1.413.480.7346 fax
> http://www.hotsos.com
>
>
>
