Re: Re: cvs: pear /MDB2/MDB2/Driver oci8.php

On 9/26/06, Lukas Kahwe Smith <lsmith@php.net> wrote:

Justin Patrin wrote: Do you mean convertResultRow()? This would mean that the call would have to be moved into _fillBuffer() (it is currently in fetchRow(), so this would mean a higher _fillBuffer() overhead and possibly converting rows which are not used, a-la seek) and would have to be called even if there are no types passed in (yes, I know, I should be passing in types, but it would be no good to have this fix only affect people who pass in types). I keep forgetting that some people do not use the datatype abstraction. Though I need to check if your fix now breaks things for people that do.

Yep. As per our IRC conversation, I've made this fix conditional on no types being passed in.

And, of course, convertResultRow() already does a foreach....I really don't see how we could loop through the resulting fields without....looping through the resulting fields. Something a bit better might be to pre-loop through the fields (tableInfo) and check for LOB fields, storing these in an array, then only loop through these fields for load()-ing. This should be somewhat of a speedup for large result sets. I guess this kind of optimization is not really worth the hassle. Someone using buffered results in LOBs is not all that concerned about performance I would say. So I guess we can stay with the change as is, as long as we are sure that multiple load() calls do not cause any issues. @Lorenzo: Is Firebird also affected by this issue?

@Lorenzo: see testLOBRead test I checked in CVS. It *should* show you if there is a problem. (note: my oci8 ext is crashing on this test currently, so I'm not sure. Mysql of course passes). Also as per our IRC discussion, see bug #8793. We will need to add to the LOB handler auto-buffering of LOBs if the result set is buffered (but perhaps only for oci8. Please test on other platforms e.g. Firebird, pgsql). -- Justin Patrin