Mark Hazen wrote:
> >Hmm, then create a ramdisk and read from the file virtually stored in
> >the RAM.
>
> Stas,
>
> This is an elegant solution that I had not thought of. My problem is that
I
> can't get ramdisks to work on my Red Hat 6.2 with 2.4.9 machine. But
that's
> really my problem, and
>This is a design flaw of DBI then. You might get more results if you
>post on the DBI users list. We got part of the way there by
>redefining the trace_msg function, the only part that remains is
>gathering the output of the lower-level DBD calls, that might involve
>modifying some XS code, (o
>Hmm, then create a ramdisk and read from the file virtually stored in
>the RAM.
Stas,
This is an elegant solution that I had not thought of. My problem is that I
can't get ramdisks to work on my Red Hat 6.2 with 2.4.9 machine. But that's
really my problem, and you've all been a big help.
Tha
On Thu, 7 Mar 2002, Stas Bekman wrote:
> Mark Hazen wrote:
> > That's your opinion. In my opinion, a bunch of disk IO and file seeks are a
> > waste of resources. The bigger issue here is that it is better to store in
> > memory, and it saddens me that it doesn't seem possible.
>
> Hmm, then c
Mark Hazen wrote:
> Mark Hazen wrote:
>
>>>I wish this were true, but no one will ever get IO::Scalar to catch DBI's
>>>STDERR output.
>>>
>
>>If so, it's only because STDERR under mod_perl is already tied. DBI is
>>not an external process.
>>
>
>>>Throwing all this stuff into a file is alread
On Wed, Mar 06, 2002 at 11:27:28AM -0700, Mark Hazen wrote:
> Mark Hazen wrote:
> >> I wish this were true, but no one will ever get IO::Scalar to catch DBI's
> >> STDERR output.
>
> >If so, it's only because STDERR under mod_perl is already tied. DBI is
> >not an external process.
>
> >> Throw
Mark Hazen wrote:
>> I wish this were true, but no one will ever get IO::Scalar to catch DBI's
>> STDERR output.
>If so, it's only because STDERR under mod_perl is already tied. DBI is
>not an external process.
>> Throwing all this stuff into a file is already something DBI
>> can do, but as I
On Wed, Mar 06, 2002 at 11:02:51AM -0700, Mark Hazen wrote:
>> IO::Scalar can redirect STDOUT for the mod_perl script itself, but not
any
>> external processes like DBI. I am still left without a solution. It
amazes
>> me.
>But using DBI isn't an 'external process', is it? It's a part of your
On Wed, Mar 06, 2002 at 11:02:51AM -0700, Mark Hazen wrote:
> IO::Scalar can redirect STDOUT for the mod_perl script itself, but not any
> external processes like DBI. I am still left without a solution. It amazes
> me.
But using DBI isn't an 'external process', is it? It's a part of your
proc
Mark Hazen wrote:
>> I am hoping there is a someone brilliant on this list that can help me.
A
>> little while ago, I posted to clp.perl asking how I can capture the trace
>> output from DBI into a variable. Since DBI is an external process, I
>> couldn't do it just by piping STDERR. Benjamin Go
Mark Hazen wrote:
> I am hoping there is a someone brilliant on this list that can help me. A
> little while ago, I posted to clp.perl asking how I can capture the trace
> output from DBI into a variable. Since DBI is an external process, I
> couldn't do it just by piping STDERR. Benjamin Goldb
riginal Message-
From: Paul Lindner [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 05, 2002 1:41 PM
To: Mark Hazen
Cc: [EMAIL PROTECTED]
Subject: Re: Breaks in mod_perl, works in Perl
I'm not sure if this will work, but you might override DBI's notion of
a trace function. If you loo
EMAIL PROTECTED]
Subject: RE: Breaks in mod_perl, works in Perl
At 1:32 PM -0700 3/5/02, Mark Hazen wrote:
>I'm sorry I didn't explain an important component. Since I am dealing with
>a few hundred requests per minute (this was got me onto mod_perl to begin
>with), then using D
At 1:32 PM -0700 3/5/02, Mark Hazen wrote:
>I'm sorry I didn't explain an important component. Since I am dealing with
>a few hundred requests per minute (this was got me onto mod_perl to begin
>with), then using DBI's ability to write to a file would vastly overwhelm my
>system.
I don't get it
Mark Hazen wrote:
> I'm sorry I didn't explain an important component. Since I am dealing with
> a few hundred requests per minute (this was got me onto mod_perl to begin
> with), then using DBI's ability to write to a file would vastly overwhelm my
> system.
Won't capturing that much data in RA
I'm not sure if this will work, but you might override DBI's notion of
a trace function. If you look in DBI.pm you'll see this line:
*trace_msg = \&DBD::_::common::trace_msg;
It appears that DBI uses the trace_msg function in the bowels of DBD
to actually do the printing. Now, you can very l
Robert Landrum [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 05, 2002 1:25 PM
To: Mark Hazen; [EMAIL PROTECTED]
Subject: Re: Breaks in mod_perl, works in Perl
At 1:14 PM -0700 3/5/02, Mark Hazen wrote:
>I am hoping there is a someone brilliant on this list that can help me. A
>little w
At 1:14 PM -0700 3/5/02, Mark Hazen wrote:
>I am hoping there is a someone brilliant on this list that can help me. A
>little while ago, I posted to clp.perl asking how I can capture the trace
>output from DBI into a variable. Since DBI is an external process, I
>couldn't do it just by piping ST
18 matches
Mail list logo
