Bug #69107 for DBIx-Class: _connect() method overrides Apache::DBI::connect

Mon Jun 27 17:03:41 2011 PHRED [...] cpan.org - Ticket created

Subject:

_connect() method overrides Apache::DBI::connect

Is there a reason that Apache::DBI::connect needs to be overridden as in this code snippet? This code doesn't appear to be functioning in my mod_perl instance and instead is connecting via Apache::DBI::connect, but it might be causing problems elsewhere. As one of the Apache::DBI maintainers I'd like to get an idea of any technical issues with using Apache::DBI with DBIx::Class and hopefully find a better solution. Thanks! 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) { 1238 $old_connect_via = $DBI::connect_via; 1239 $DBI::connect_via = 'connect'; 1240 }

Tue Jun 28 14:55:49 2011 ribasushi [...] leporine.io - Correspondence added

Subject:	Re: [rt.cpan.org #69107] _connect() method overrides Apache::DBI::connect
Date:	Tue, 28 Jun 2011 14:55:38 -0400
To:	via RT <bug-DBIx-Class [...] rt.cpan.org>
From:	Peter Rabbitson <ribasushi [...] cpan.org>

On Mon, Jun 27, 2011 at 05:03:44PM -0400, via RT wrote: Show quoted text

> Mon Jun 27 17:03:41 2011: Request 69107 was acted upon. > Transaction: Ticket created by PHRED > Queue: DBIx-Class > Subject: _connect() method overrides Apache::DBI::connect > Broken in: 0.08192 > Severity: Critical > Owner: Nobody > Requestors: PHRED@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > > > > Is there a reason that Apache::DBI::connect needs to be overridden as in this code snippet? This > code doesn't appear to be functioning in my mod_perl instance and instead is connecting via > Apache::DBI::connect, but it might be causing problems elsewhere. As one of the Apache::DBI > maintainers I'd like to get an idea of any technical issues with using Apache::DBI with DBIx::Class > and hopefully find a better solution. Thanks! > > 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) { > 1238 $old_connect_via = $DBI::connect_via; > 1239 $DBI::connect_via = 'connect'; > 1240 } >

This is pretty old code, Feb 14th 2006. I do not have an immediate answer at this point, will have to ask around. In your report you say "this code doesn't appear to be functioning" - why is this? is your ENV different? Or is Apache::DBI lazy-loaded? Cheers

Tue Jun 28 14:55:52 2011 The RT System itself - Status changed from 'new' to 'open'

Mon Jul 04 10:26:14 2011 rt-cpan [...] trout.me.uk - Correspondence added

On Tue Jun 28 14:55:49 2011, RIBASUSHI wrote: Show quoted text

> On Mon, Jun 27, 2011 at 05:03:44PM -0400, via RT wrote:

> > Mon Jun 27 17:03:41 2011: Request 69107 was acted upon. > > Transaction: Ticket created by PHRED > > Queue: DBIx-Class > > Subject: _connect() method overrides Apache::DBI::connect > > Broken in: 0.08192 > > Severity: Critical > > Owner: Nobody > > Requestors: PHRED@cpan.org > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > > > > > > > Is there a reason that Apache::DBI::connect needs to be overridden

> as in this code snippet? This

> > code doesn't appear to be functioning in my mod_perl instance and

> instead is connecting via

> > Apache::DBI::connect

In that case I'd like to know why, since DBIx::Class overrides Apache::DBI intentionally. Since DBIx::Class does its own connection management and has well known semantics as to $dbh lifetime, allowing Apache::DBI to affect the connect process at all would be a bug. Just because globally monkeypatching the DBI connection management is useful for old broken CGI scripts you're trying to run under mod_perl doesn't mean that it should also affect DBIx::Class. I understand that Apache::DBI needs to screw with things globally in order to get old, badly written code to work better, but for new code that's already written properly, it should be bypassed - so we do. Ideally, Apache::DBI should be updated to provide an official way to bypass its functionality, and then DBIx::Class could detect a sufficiently recent Apache::DBI and use that mechanism. But we can and should always bypass Apache::DBI if it's loaded - it's completely the wrong answer for DBIx::Class code and historically its connection management has been much less robust.

Mon Jul 04 13:13:31 2011 fred [...] redhotpenguin.com - Correspondence added

Subject:	Re: [rt.cpan.org #69107] _connect() method overrides Apache::DBI::connect
Date:	Mon, 4 Jul 2011 10:13:21 -0700
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Fred Moyer <fred [...] redhotpenguin.com>

Sorry for the delay in responding. Here's how I call Apache::DBI in my startup.pl. With debug enabled, the error logs indicate successful connections, pings, and disconnects on child httpds. So Apache::DBI appears to be functioning normally. use Apache::DBI (); ... use DBI (); use DBIx::Class (); $Apache::DBI::DEBUG = 2; my $db_connect_params = My::Model->connect_params; Apache::DBI->connect_on_init( @{$db_connect_params} ); Apache::DBI->setPingTimeOut( $db_connect_params->[0], 5 ); # Disconnect DBIx::Class database connection in main httpd process # so forked child httpds will connect on init. My::Model->connect->disconnect; $DBI::connect_via = 'Apache::DBI::connect'; On Tue, Jun 28, 2011 at 11:55 AM, Peter Rabbitson via RT <bug-DBIx-Class@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > > > On Mon, Jun 27, 2011 at 05:03:44PM -0400, via RT wrote:

>> Mon Jun 27 17:03:41 2011: Request 69107 was acted upon. >> Transaction: Ticket created by PHRED >> Queue: DBIx-Class >> Subject: _connect() method overrides Apache::DBI::connect >> Broken in: 0.08192 >> Severity: Critical >> Owner: Nobody >> Requestors: PHRED@cpan.org >> Status: new >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > >> >> >> Is there a reason that Apache::DBI::connect needs to be overridden as in this code snippet? This >> code doesn't appear to be functioning in my mod_perl instance and instead is connecting via >> Apache::DBI::connect, but it might be causing problems elsewhere. As one of the Apache::DBI >> maintainers I'd like to get an idea of any technical issues with using Apache::DBI with DBIx::Class >> and hopefully find a better solution. Thanks! >> >> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) { >> 1238 $old_connect_via = $DBI::connect_via; >> 1239 $DBI::connect_via = 'connect'; >> 1240 } >>

> > This is pretty old code, Feb 14th 2006. I do not have an immediate answer > at this point, will have to ask around. In your report you say "this code > doesn't appear to be functioning" - why is this? is your ENV different? > Or is Apache::DBI lazy-loaded? > > Cheers > >

Mon Jul 04 13:18:18 2011 fred [...] redhotpenguin.com - Correspondence added

Subject:	Re: [rt.cpan.org #69107] _connect() method overrides Apache::DBI::connect
Date:	Mon, 4 Jul 2011 10:18:09 -0700
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Fred Moyer <fred [...] redhotpenguin.com>

Thanks for weighing in Matt. Can you give some specific reasons as to why Apache::DBI and DBIx::Class should not be used together? I've been using both for about 4-5 years now and Apache::DBI has not created any visible problems. "Ideally, Apache::DBI should be updated to provide an official way to bypass its functionality, and then DBIx::Class could detect a sufficiently recent Apache::DBI and use that mechanism." There is the foolproof way of not using Apache::DBI at all to bypass the functionality. I'd rather document known incompatibilities within Apache::DBI rather than having DBIx::Class disable it without the user knowing. I use new, well written code with both Apache::DBI and DBIx::Class, so I'd like to hear the details on what problems I should be expecting by using the two together. On Mon, Jul 4, 2011 at 7:26 AM, MSTROUT via RT <bug-DBIx-Class@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > > > On Tue Jun 28 14:55:49 2011, RIBASUSHI wrote:

>> On Mon, Jun 27, 2011 at 05:03:44PM -0400, via RT wrote:

>> > Mon Jun 27 17:03:41 2011: Request 69107 was acted upon. >> > Transaction: Ticket created by PHRED >> > Queue: DBIx-Class >> > Subject: _connect() method overrides Apache::DBI::connect >> > Broken in: 0.08192 >> > Severity: Critical >> > Owner: Nobody >> > Requestors: PHRED@cpan.org >> > Status: new >> > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > >> > >> > >> > Is there a reason that Apache::DBI::connect needs to be overridden

>> as in this code snippet? This

>> > code doesn't appear to be functioning in my mod_perl instance and

>> instead is connecting via

>> > Apache::DBI::connect

> > In that case I'd like to know why, since DBIx::Class overrides > Apache::DBI intentionally. > > Since DBIx::Class does its own connection management and has well known > semantics as to $dbh lifetime, allowing Apache::DBI to affect the > connect process at all would be a bug. > > Just because globally monkeypatching the DBI connection management is > useful for old broken CGI scripts you're trying to run under mod_perl > doesn't mean that it should also affect DBIx::Class. > > I understand that Apache::DBI needs to screw with things globally in > order to get old, badly written code to work better, but for new code > that's already written properly, it should be bypassed - so we do. > > Ideally, Apache::DBI should be updated to provide an official way to > bypass its functionality, and then DBIx::Class could detect a > sufficiently recent Apache::DBI and use that mechanism. > > But we can and should always bypass Apache::DBI if it's loaded - it's > completely the wrong answer for DBIx::Class code and historically its > connection management has been much less robust. >

Tue Jul 05 12:11:39 2011 PHRED [...] cpan.org - Severity Critical changed to Important

Thu Jul 14 18:27:48 2011 rt-cpan [...] trout.me.uk - Correspondence added

On Mon Jul 04 13:18:18 2011, fred@redhotpenguin.com wrote: Show quoted text

> Thanks for weighing in Matt. Can you give some specific reasons as to > why Apache::DBI and DBIx::Class should not be used together? I've > been using both for about 4-5 years now and Apache::DBI has not > created any visible problems.

I'm unsure what: "Since DBIx::Class does its own connection management and has well known semantics as to $dbh lifetime, allowing Apache::DBI to affect the connect process at all would be a bug." doesn't make clear? Since Apache::DBI is a process global change, we need to revert back to the standard, DBIx::Class default, behaviour by default, and perhaps then also allow an option to, for a particular $schema instance, re-enable the behaviour. The point here is to prevent 'use Apache::DBI' in e.g. an Apache::Registry config section affecting a DBIx::Class using app loaded elsewhere. "Don't use Apache::DBI" doesn't achieve that - the ::Registry config block needs to do so, so it's up to DBIx::Class to ensure that it doesn't affect our users. If a user wants Apache::DBI semantics rather than DBIx::Class semantics from My::Schema->connect, I would be happy for them to have a way to ask for them. But I'm not happy with the action-at-a-distance of having the alternative semantics forced upon them merely by a module being loaded in a (potentially unrelated) different piece of code.

Tue Jul 19 09:36:06 2011 ribasushi [...] leporine.io - Correspondence added

On Mon Jul 04 13:18:18 2011, fred@redhotpenguin.com wrote: Show quoted text

> Thanks for weighing in Matt. Can you give some specific reasons as to > why Apache::DBI and DBIx::Class should not be used together? I've > been using both for about 4-5 years now and Apache::DBI has not > created any visible problems.

Hi Fred, Just wondering where to go with this ticket. Is Matt's second answer in this thread sufficient, or do you have further concerns? Cheers

Tue Jul 19 10:58:08 2011 fred [...] redhotpenguin.com - Correspondence added

CC:	PHRED [...] cpan.org
Subject:	Re: [rt.cpan.org #69107] _connect() method overrides Apache::DBI::connect
Date:	Tue, 19 Jul 2011 07:57:52 -0700
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Fred Moyer <fred [...] redhotpenguin.com>

On Thu, Jul 14, 2011 at 3:27 PM, MSTROUT via RT <bug-DBIx-Class@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > > "Since DBIx::Class does its own connection management and has well known > semantics as to $dbh lifetime, allowing Apache::DBI to affect the > connect process at all would be a bug."

Can you point me in the direction of where these connection management specifics and dbh lifetime details are documented, or are in the codebase? I'd really like to be familiar with these so that I can understand this issue as well as the DBIx::Class developers and make any needed changes to Apache::DBI so everyone is satisfied. Show quoted text

> If a user wants Apache::DBI semantics rather than DBIx::Class semantics > from My::Schema->connect, I would be happy for them to have a way to ask > for them. But I'm not happy with the action-at-a-distance of having the > alternative semantics forced upon them merely by a module being loaded > in a (potentially unrelated) different piece of code.

That's what I'm after here, a way to make Apache::DBI and DBIx::Class work well together without needed the mentioned action-at-a-distance approach of having alternative semantics forced upon the user by DBIx::Class. So far I don't see any specific issues with using Apache::DBI and DBIx::Class; it more looks like a case of DBIx::Class developers being unhappy with the way Apache::DBI works. That's fair, but I would like to get at the *specific* technical issues here that are causing problems. I found a couple of threads about Apache::DBI and DBIx::Class idealogical differences, but so far haven't come across any with technical details of problems. http://lists.scsys.co.uk/pipermail/catalyst/2007-July/014637.html http://lists.scsys.co.uk/pipermail/dbix-class/2006-April/001153.html So yeah, what specific technical problems are standing in the way of making these two modules work well together?

Wed Jul 20 02:45:07 2011 rt-cpan [...] trout.me.uk - Correspondence added

On Tue Jul 19 10:58:08 2011, fred@redhotpenguin.com wrote: Show quoted text

> On Thu, Jul 14, 2011 at 3:27 PM, MSTROUT via RT > <bug-DBIx-Class@rt.cpan.org> wrote:

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=69107 > > > "Since DBIx::Class does its own connection management and has well known > > semantics as to $dbh lifetime, allowing Apache::DBI to affect the > > connect process at all would be a bug."

> > Can you point me in the direction of where these connection management > specifics and dbh lifetime details are documented, or are in the > codebase? I'd really like to be familiar with these so that I can > understand this issue as well as the DBIx::Class developers and make > any needed changes to Apache::DBI so everyone is satisfied.

DBIx::Class provides a single persistent $dbh per $schema. It is not touched by anybody else. Apache::DBI breaks this. Show quoted text

> That's what I'm after here, a way to make Apache::DBI and DBIx::Class > work well together without needed the mentioned action-at-a-distance > approach of having alternative semantics forced upon the user by > DBIx::Class.

What are you talking about? The specific problem here is Apache::DBI's entire purpose is action at a distance. We are not doing action-at-a-distance. We are undoing yours. All I want is a documented API for saying "Apache::DBI, please un-monkeypatch my DBI for this scope because I don't want you to inflict action-at-a-distance on DBIx::Class" That's it. Or we can fix our current "disable the stupid thing with extreme prejudice" code. Either way works for me. There is no such thing as "work well together". Apache::DBI's entire purpose is to solve a problem that DBIx::Class used correctly does not have. Apache::DBI's entire purpose is to patch around badly written DBI code and make it use a persistent $dbh in spite of the original author's incompetence. That's a really nice thing to have available. But it's no use whatsoever to our users, so I don't want to inflict it on them. Please give us a way to turn Apache::DBI *off*, and I'll happily take a patch that lets you say "please let Apache::DBI do its action-at-a-distance thing" explicitly to DBIx::Class so that it's clear that you're asking for weird global effects. There is no bug in Apache::DBI to be fixed here. It simply does something that we DO NOT WANT because we ALREADY CACHE THE DATABASE HANDLE. If a DBIx::Class user is creating their $schema again and again, that's a bug to be fixed. Loading Apache::DBI is just papering over that bug. I refuse to penalize everybody using DBIx::Class correctly just because Apache::DBI has been loaded because somebody used DBI a stupid way somewhere else in the same perl5 VM. So. I will take a patch to make our turning Apache::DBI *off* more elegant. I will take a patch to optionally let the user say they want the Apache::DBI monkeypatch - something like 'allow_apache_dbi_connect_override' as a storage option. But you're the one forcing semantics on the user, not us. So I'm going to mark this bug as rejected now. If you want to engage in further discussion that isn't the submission of the above suggested patches, please come and talk to me on IRC, because I'm repeating myself over and over here and I'm sick of it now. REJECTED: THE ONLY BUG HERE IS APACHE::DBI.

Wed Jul 20 02:45:10 2011 rt-cpan [...] trout.me.uk - Status changed from 'open' to 'rejected'