Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Mon, Jun 27, 2011 at 12:53 PM, Octavian Rasnita orasn...@gmail.com 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 already manages its connections for you, and therefore it
cannot benefit from Apache::DBI under any scenario. It makes one
connection per-process, and keeps that connection persistent,
reconnecting only if the connection appears to have died, or if you
fork/thread over to another process/thread-id. The only Apache::DBI
issue in DBIx::Class is that Apache::DBI will actually thwart
DBIx::Class's connection management code, and cause it to use the same
(and invalid) connection in a new process, in cases such as (as
mentioned above) if you make a DBI connection before forking in a
prefork mod_perl server.
To work around this, DBIx::Class has specific code in it to work
around Apache::DBI, nullifying the effects of Apache::DBI on
DBIx::Class. Essentially, loading Apache::DBI should change nothing
and be rather pointless under DBIx::Class.
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 }
And it is also apparently not working as they expected:
[Mon Jun 27 13:05:17 2011] [notice] Apache/2.2.17 (Unix)
mod_apreq2-20090110/2.8.0 mod_perl/2.0.5 Perl/v5.12.3 configured --
resuming normal operations
8879 Apache::DBI new connect to 'dbname='...
In my startup.pl (My::Model is DBIx::Class based):
$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 );
# delete this line and I will beat you with a stick (note to self)
My::Model-connect-disconnect;
$DBI::connect_via = 'Apache::DBI::connect';
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
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 apparently not working as they expected:
[Mon Jun 27 13:05:17 2011] [notice] Apache/2.2.17 (Unix)
mod_apreq2-20090110/2.8.0 mod_perl/2.0.5 Perl/v5.12.3 configured --
resuming normal operations
8879 Apache::DBI new connect to 'dbname='...
In my startup.pl (My::Model is DBIx::Class based):
$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 );
# delete this line and I will beat you with a stick (note to self)
My::Model-connect-disconnect;
$DBI::connect_via = 'Apache::DBI::connect';
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
Best,
David
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
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 having read that, I strongly recommend against the use of DBIx-Connector. But then I'm just a production DBA :) Dave -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Mon, Jun 27, 2011 at 1:22 PM, David E. Wheeler da...@kineticode.com 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 }
DBIx::Connector does the same thing.
I just filed an RT ticket with DBIx::Class for this asking for some
details on why it is necessary. Hoping that they'll be willing to
share some of their technical concerns. I'm not sure why this code
isn't working in my environment, but it could be because I have
Apache::DBI setup differently than they do.
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 connection
caching module as opposed to a drop in module for mod_perl. For most
mod_perl users, Apache::DBI provides a performance improvement with Pg
and Oracle for just a few lines in your startup.pl.
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
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 against the use of DBIx-Connector. But then I'm just a production DBA :) Me too. What weaknesses do you see in it? Best, David
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
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 connection caching module as opposed to a drop in module for mod_perl. For most mod_perl users, Apache::DBI provides a performance improvement with Pg and Oracle for just a few lines in your startup.pl. No. DBIx::Connector doesn't do caching at all. That's the point, really. Best, David
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
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 that, I strongly recommend against the use of DBIx-Connector. But then I'm just a production DBA :) Me too. What weaknesses do you see in it? What's the point of it? As far as I can see the author claims to have issues with Apache::DBI and does not like the hidden aspect. I have never experienced his issues and the hidden aspect is the good part. Apache::DBI can be deployed by an admin without consulting the developers, without affecting their code. It does not require any use statements in the source code. He claims that it does no caching across threads. Why not? If the thread uses the same connection/session state then why not use a cached connection. If it doesn't then it is the developers responsibility. Transaction management: I cannot see the point of it, however, I can see the utility to others. My personal viewpoint is that a if good commit, else rollback make what's happening explicit which when dealing with a db is extremely useful. Mind you I believe AutoCommit is a bad thing and should never have been made. My shop also use stored procs for almost everything. Wish DBD::Pg would let me read cursors, like DBD::Oracle, that's what I really need. I suppose it is all a matter of personal preference but I have found that the further removed the developer is from the database the worse they are at accessing it. DBIx::Class is the perfect example. Please spare me the hassle of trying to debug/explain/improve any code that uses that. I am sure that high quality code can be written using DBIx::Class but I have yet to see it. Oops, just realized you are the author :). Please don't take anything above personally, I just think that if you wanted transaction management, it would have been better to write a module that just does that and nothing else. Then, if a developer in my shop wanted to use it I could load it without having to worry about apache managing two connection pools. IMHO, worth exactly what you paid for it Dave Best, David -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
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 instead for years. Over time, Apache::DBI picked up some other features which are useful in mod_perl. If you're using something else, you should make sure you have these or know why you don't need them. - Startup safety. This prevents sharing of connections opened in the parent process during startup. Apache::DBI does this by not caching connections during startup. DBIx::Class does this by making a new connection if you fork or start a new thread. Note the stuff about InactiveDestroy in the DBI docs if you use DBIx::Class or DBIx::Connector. - Automatic rollback. Apache::DBI issues a rollback at the end of every request where the DBI connection was not opened in AutoCommit mode. This is to prevent a die() during a transaction from leaving your database in a bad state. If you use subroutine blocks wrapped in eval (e.g. the transaction stuff in DBIx::Connector), this should not be necessary, but make sure you ALWAYS do it that way if you're counting on that to protect you. I agree that trashing Apache::DBI is not very useful, but you should also know what Apache::DBI was meant for and what it's limitations are. - Perrin
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
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 hidden aspect is the good part. Apache::DBI can be deployed by an admin without consulting the developers, without affecting their code. It does not require any use statements in the source code. Yeah, too magical. I removed support for it in Bricolage years ago, though I can't remember the details of why anymore. connect_cached() worked much better for me (though it's kind of a PITA to set up). He claims that it does no caching across threads. Why not? If the thread uses the same connection/session state then why not use a cached connection. If it doesn't then it is the developers responsibility. Most database handles are not thread-safe. Transaction management: I cannot see the point of it, however, I can see the utility to others. My personal viewpoint is that a if good commit, else rollback make what's happening explicit which when dealing with a db is extremely useful. Yeah, that interface is a convenience. I think it's much nicer to scope things within a subref. Mind you I believe AutoCommit is a bad thing and should never have been made. I don't think AutoCommit was a mistake. These days I always connect with AutoConnect explicitly set to true, as otherwise I might have a transaction running for a long time until the first connection comes in. My shop also use stored procs for almost everything. Wish DBD::Pg would let me read cursors, like DBD::Oracle, that's what I really need. I don't understand. PostgreSQL supports cursors, and you can read from them using FETCH. http://www.postgresql.org/docs/current/static/sql-fetch.html Might be my lack of knowledge of Oracle at work here, though. I suppose it is all a matter of personal preference but I have found that the further removed the developer is from the database the worse they are at accessing it. DBIx::Class is the perfect example. Please spare me the hassle of trying to debug/explain/improve any code that uses that. I am sure that high quality code can be written using DBIx::Class but I have yet to see it. Yes, I'm not a fan of ORMs because they tend to create bad queries, among other things. This is why DBIx::Connector is much more focused on adding interfaces to a connection, and not to querying the database. Oops, just realized you are the author :). :-) Please don't take anything above personally, I just think that if you wanted transaction management, it would have been better to write a module that just does that and nothing else. Then, if a developer in my shop wanted to use it I could load it without having to worry about apache managing two connection pools. Well, DBIx::Connector does not do connection pooling (or caching), so that wouldn't be a problem. IMHO, worth exactly what you paid for it I paid quite a lot of it in terms of my time to develop the interface. So I'm rather fond of it. Varying opinions of course welcome. Best, David
