"Chris R. Donnelly" <[EMAIL PROTECTED]> writes: [I thought I would Cc: dbi-dev, since this seems to be of general interest; I hope that is ok.]
> I believe I actually may have resolved that in the version I had written > up... I started from DBI 1.38 (which has the execute_for_fetch()) method and > had basically hit a wall with how to do the bind variables, which > fortunately was the part you had done :). I merged your changes in with the > ones I had done. I am still cleaning up some of the minor details (like > status handling). > > BTW, is there a need for doing data in a column major format? It seems to > perform just fine with row major format, and I believe the latest > execute_array builds its tuples from the column-style binds... Well, this question is essentially the "outstanding issue" I mentioned. If writing new code I think I would find the row-format most natural, however old code would probably use execute_array(), which is column major format. Column format is probably also more memory efficient, though that may be of less inportance. Does DBI 1.38 have an API that takes an array of rows (which should be the usual end-user interface rather than the more abstract callback method of execute_for_fetch())? If not, it should probably be added, I think I put in a row-wise option in my execute_array patch. Oracle OCI needs to know the total row-count up-front, so the only way to implement execute_for_fetch() is to buffer rows in an array before calling Oracle. If I start with an array of rows, I find it somewhat unsatisfactory if the array is first taken apart in the execute_for_fetch() callback, then reassembled in smaller pieces by execute_for_fetch() before finally making it to Oracle. For that reason I ended up implementing execute_array() directly as well as execute_for_fetch(), and even made the driver support both column-wise and row-wise operations natively. So the functionality is there, it is just a matter of deciding which parts to pick to get a clean implementation and interface with DBI. I think Tim will have some opinions when he is done with the next DBD::Oracle. Hm, I think my own suggestion will be to let DBD::Oracle implement exeute_for_fetch() by buffering callback rows (there is an old post by Tim in dbi-dev that outlines this). Then there could be lower-level DBD::Oracle specific methods (or possibly new lower-level DBI methods) for directly accessing rowwise and columnwise array opeations for those who need the efficiency and control. - Kristian. > > Thank you for your assistance! I definitely couldn't do it without your > help :) > > # Chris > > Chris Donnelly [EMAIL PROTECTED] > Software Systems Architect > Digital Motorworks > Austin, TX (512) 692-1101 > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2003 2:07 AM > To: [EMAIL PROTECTED] > Subject: Re: DBD::Oracle and bulk binds via execute_array > > "Chris R. Donnelly" <[EMAIL PROTECTED]> writes: > > > Hi! Sorry to bother you, but I found an entry on dbi-dev where you had > > mentioned you were working on making DBD::Oracle support execute_array > > properly. Did you manage to get it working? I was working on making it > > implement it myself when I happened to find your article... if not, any > > particular issues that stopped you? > > Well, I did manage to get something working; in fact I posted a patch to > dbi-dev (against DBD::Oracle 1.14) with an implementation: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg02296.html > http://aspn.activestate.com/ASPN/Mail/Message/perl-DBI-dev/1686549 > > No real issues in the implementation; mainly just a lot of time spent > learning the deeper regions of both DBD::Oracle and OCI. > > I have briefly tested that the patch actually works and gives a nice > speed improvement. I have postponed extensive testing and memory leak > check until we actually need this for production code, but if you were > to start using it first and found any specific problems I would most > likely be willing to fix it quickly. > > I have an outstanding issue with Tim Bunce (DBI/DBD::Oracle author) > about how to finalize the internal interface between DBI and > DBD::Oracle::execute_array(), however that should not affect code that > merely uses execute_array() and this native DBD::Oracle implementation. > > - Kristian. > > -- > Kristian Nielsen [EMAIL PROTECTED] > Development Manager, Sifira A/S > > >
