Re: Re: cvs: pear /MDB2/MDB2/Driver oci8.php
| From: | Justin Patrin | Date: | Wed, 27 Sep 2006 17:52:18 +0000 |
| Subject: | Re: Re: cvs: pear /MDB2/MDB2/Driver oci8.php | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-44100@lists.php.net to get a copy of this message | ||
On 9/27/06, Justin Patrin <papercrane@gmail.com> wrote:
On 9/27/06, Lukas Kahwe Smith <lsmith@php.net> wrote: Justin Patrin wrote:Got it fixed. Reboot...Yes, it *should* cover the test case. I still need to debug what oci8 is doing to crash to make sure the test case works. Does the ibase extWell, I got the test case to run by re-preparing the statement for each record to insert. However, it's not failing, so I must have done something wrong. Unfortunately, before I could start debugging, oracle decided to die on me. It's not starting up any more and any command I run immediately takes all CPU.....
I assume you were testing on *nix? It crashes on windows as well. Could you file a bug report and include a backtrace for Tony to look at? http://pecl.php.net/bugs/bug.php?id=8800 BTW: He said he did not yet find a solution to make it possible to load() a LOB later. So he is aware of the issue and just did not find a work around :( I imagine it's an underlying DB "problem". You're not really supposed to be buffering results like this while reading LOBs... Which reminds me, why does MDB2 by default buffer results? This seems like it's the exact opposite of what it should do. By default wouldn't people want to allow the records to be read and then freed?Aha...the buffered result only buffers records as you read them. I should have realized that. This is somewhat better than what I was thinking. However, the results (for oci8 at least) are still buffered in memory. And, of course, this is as it has to be as the oci8 ext does not have seek support.... I'd still like to know why buffered is the default, though. It seems to me that most uses don't tend to re-use results and that the buffering of rows in memory isn't a great thing to do by default... Oh, and BTW, the test case now works. I hadn't realized that the rows were still fetched as you fetch them. Doing a seek(0) and re-fetching triggers the bug (as does calling numRows() as SDG does). I've re-run the test on mysql(i), pgsql (just set up), and oci8. oci8 fails as expected, all others pass. @Lorenzo, could you try the test on ibase again? (testlobread) -- Justin Patrin