On Jun 28, 2011, at 11:34 AM, Dave Morgan wrote:
> First off, please let me apologize for the tone of my last email,
> It was certainly not what I intended.
No worries. I assumed it was a caffeine shortage. That's what I suffer from
sometimes. :-)
> I have to stop having discussions about syste
Hi Randal,
>>>
>>> You lost me. But really, I strongly recommend against the use of
Apache::DBI. Some discussion here:
>>>
>>>
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>>>
>
>Dave> And having read that, I strongly recommend against the use of
DBIx-Conne
> "Dave" == Dave Morgan writes:
>>
>> You lost me. But really, I strongly recommend against the use of
>> Apache::DBI. Some discussion here:
>>
>> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>>
Dave> And having read that, I strongly recommend against the
First off, please let me apologize for the tone of my last email,
It was certainly not what I intended.
I have to stop having discussions about system design and
philosophy after having meetings with a developer who's most
intelligent statement was "It works on my machine". Cold Fusion not
mod-pe
On Jun 27, 2011, at 4:20 PM, Dave Morgan wrote:
> What's the point of it?
First of all, what Perrin said. :-)
> As far as I can see the author claims to have issues with Apache::DBI and
> does not
> like the hidden aspect.
FWIW, I am the author.
> I have never experienced his "issues" and the
Please calm down, folks.
Apache::DBI is a module that was designed to help with porting legacy
CGI applications to mod_perl. It's a valid criticism to say that the
action-at-a-distance parts of it are undesirable in new mod_perl
applications. Personally, I have used mostly custom caching code
in
On 27/06/11 04:27 PM, David E. Wheeler wrote:
On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote:
You lost me. But really, I strongly recommend against the use of Apache::DBI.
Some discussion here:
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
And having read
On Jun 27, 2011, at 2:17 PM, Fred Moyer wrote:
>> You lost me. But really, I strongly recommend against the use of
>> Apache::DBI. Some discussion here:
>> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>
> It seems like you are looking for a more feature rich db c
On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote:
>> You lost me. But really, I strongly recommend against the use of
>> Apache::DBI. Some discussion here:
>>
>>
>> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>>
>
> And having read that, I strongly recommend a
On Mon, Jun 27, 2011 at 1:22 PM, David E. Wheeler wrote:
> On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
>
>> Wow, that's obnoxious:
>>
>> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
>> 1238 $old_connect_via = $DBI::connect_via;
>> 1239 $DBI::connect_via = 'connect';
>> 1240 }
On 27/06/11 02:22 PM, David E. Wheeler wrote:
On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
Snip .
You lost me. But really, I strongly recommend against the use of Apache::DBI.
Some discussion here:
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
And
On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
> Wow, that's obnoxious:
>
> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
> 1238 $old_connect_via = $DBI::connect_via;
> 1239 $DBI::connect_via = 'connect';
> 1240 }
DBIx::Connector does the same thing.
> And it is also apparentl
On Mon, Jun 27, 2011 at 12:53 PM, Octavian Rasnita wrote:
> Here is a comment that might be helpful, because it also explains why
> DBIx::Class can work with Apache::DBI (and why it is not needed):
>
> http://lists.scsys.co.uk/pipermail/dbix-class/2006-April/001153.html
>
> ""
> DBIx::Class alrea
John Siracusa wrote:
Even without threads, wouldn't you rather have each apache child pulling
connections from a shared, server-wide pool rather than holding onto at
least one connection a piece whether they need it or not?
Sure. Can you figure out a way to do it?
Probably not in Perl 5 and apach
On 8/13/04 10:34 PM, John Siracusa wrote:
> In the situation I described, for example, print will happily return 1 so long
> as what it's printing fits in the output buffer, regardless of whether or not
> the data is actually going to make it to the disk.
Er, that should read "regardless of whethe
On 8/13/04 5:22 PM, Perrin Harkins wrote:
> On Fri, 2004-08-13 at 17:05, John Siracusa wrote:
>> Even without threads, wouldn't you rather have each apache child pulling
>> connections from a shared, server-wide pool rather than holding onto at
>> least one connection a piece whether they need it o
On 8/13/04 5:23 PM, Perrin Harkins wrote:
> On Fri, 2004-08-13 at 17:15, John Siracusa wrote:
>> Something tells me you haven't been bitten by this bug yet, but let me save
>> you the grief. When, say, your disk fills up and you let that file handle
>> go out of scope, close() will silently fail w
Stas Bekman wrote:
Support for threads is only partial functionality of DBI::Pool.
Otherwise it should be a ground-up rewrite based on the experiences with
Apache::DBI and other wrappers so far. Apache::DBI should become just a
thin wrapper on top of DBI::Pool, to handle things like connect_on_i
Perrin Harkins wrote:
On Fri, 2004-08-13 at 16:37, Stas Bekman wrote:
IMHO, that should be folded into DBI::Pool
I'm not really interested in tackling pooling, since I don't plan to run
threads.
Support for threads is only partial functionality of DBI::Pool. Otherwise
it should be a ground-up r
On Fri, 2004-08-13 at 17:15, John Siracusa wrote:
> Something tells me you haven't been bitten by this bug yet, but let me save
> you the grief. When, say, your disk fills up and you let that file handle
> go out of scope, close() will silently fail when trying to flush the buffers
> to disk.
If
On Fri, 2004-08-13 at 17:05, John Siracusa wrote:
> Even without threads, wouldn't you rather have each apache child pulling
> connections from a shared, server-wide pool rather than holding onto at
> least one connection a piece whether they need it or not?
Sure. Can you figure out a way to do i
On Fri, 13 Aug 2004 17:02:27 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > > Now that Perl has lexically scoped filehandles, there isn't any reason
> > > to explicitly call close() in most cases. ;)
> >
> > Tsk, for shame. Just wait until you forget to call close() after writing to
> > a fi
On Fri, 13 Aug 2004 16:45:59 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 16:37, Stas Bekman wrote:
> > IMHO, that should be folded into DBI::Pool
>
> I'm not really interested in tackling pooling, since I don't plan to run
> threads. All that I really want my module t
On Fri, 2004-08-13 at 16:43, John Siracusa wrote:
> It
> just seemed odd to me to be doing stuff in service of Apache::DBI, which was
> totally transparent until then.
That's one of the things I don't like about Apache::DBI. I don't want
it to be magical.
> > Now that Perl has lexically scoped f
On Fri, 13 Aug 2004 13:37:55 -0700, Stas Bekman wrote:
> Perrin Harkins wrote:
> > I would like to replace Apache::DBI with something oriented
> > towards connection management rather than porting old CGI scripts. I
> > don't like the disabling of disconnect. The old Apache::DBI could stick
> > a
On Fri, 2004-08-13 at 16:37, Stas Bekman wrote:
> IMHO, that should be folded into DBI::Pool
I'm not really interested in tackling pooling, since I don't plan to run
threads. All that I really want my module to do is extend the
DBI->connect_cached() method by adding the cleanup handler stuff from
On Fri, 13 Aug 2004 16:22:00 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
>> So what you're saying is that DBIx::* and Apache::DBI will simply never get
>> along because they both want to do the same thing, but use different (and
>> apparently incompatible) methods to do so?
>
> They both subc
Perrin Harkins wrote:
Er, yeah, "essentially" :) All the crazy re-blessing that goes on is
quite
a mess, IMO.
Agreed. I would like to replace Apache::DBI with something oriented
towards connection management rather than porting old CGI scripts. I
don't like the disabling of disconnect. The old
> Er, yeah, "essentially" :) All the crazy re-blessing that goes on is
quite
> a mess, IMO.
Agreed. I would like to replace Apache::DBI with something oriented
towards connection management rather than porting old CGI scripts. I
don't like the disabling of disconnect. The old Apache::DBI could
On Fri, 13 Aug 2004 12:50:44 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Also make sure that you read:
>
http://perl.apache.org/docs/1.0/guide/databases.html#Opening_Connections_With_Di
fferent_Parameters
Unfortunately, setting RootClass after the connect doesn't have the desired
effect (and
On Fri, 13 Aug 2004 12:51:32 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote:
> John Siracusa wrote:
> > On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
> >
> >>> return 200;
> >>
> >>this is wrong - you should be returning OK (0) not HTTP_OK (200) from
> >>handlers if everything is swell.
John Siracusa wrote:
On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
return 200;
this is wrong - you should be returning OK (0) not HTTP_OK (200) from
handlers if everything is swell. while 200 works in mp1 (due to mod_perl
"guessing" what you meant) you cannot do this in mod_perl 2.0.
Perrin Harkins wrote:
On Fri, 2004-08-13 at 15:25, John Siracusa wrote:
What does a DBIx::* module have to do in order to correctly call
Apache::DBI's no-op version of disconnect() when running under mod_perl with
Apache::DBI?
It needs to not set RootClass. Apache::DBI essentially subclasses DBI,
On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
> > return 200;
>
> this is wrong - you should be returning OK (0) not HTTP_OK (200) from
> handlers if everything is swell. while 200 works in mp1 (due to mod_perl
> "guessing" what you meant) you cannot do this in mod_perl 2.0. so, if
On Fri, 13 Aug 2004 15:32:03 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 15:25, John Siracusa wrote:
> > What does a DBIx::* module have to do in order to correctly call
> > Apache::DBI's no-op version of disconnect() when running under mod_perl with
> > Apache::DBI?
>
while perrin addressed your other issues, I thought I'd bring this up as a
learning point :)
>
> return 200;
this is wrong - you should be returning OK (0) not HTTP_OK (200) from
handlers if everything is swell. while 200 works in mp1 (due to mod_perl
"guessing" what you meant) you cannot do
On Fri, 2004-08-13 at 15:25, John Siracusa wrote:
> What does a DBIx::* module have to do in order to correctly call
> Apache::DBI's no-op version of disconnect() when running under mod_perl with
> Apache::DBI?
It needs to not set RootClass. Apache::DBI essentially subclasses DBI,
which is what R
What does a DBIx::* module have to do in order to correctly call
Apache::DBI's no-op version of disconnect() when running under mod_perl with
Apache::DBI?
Below is an example that illustrates a bug I found when using a particular
DBIx:: module.
---
package MyTest;
use strict;
use Apache::DBI;
us
38 matches
Mail list logo
