Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for yourweb application?]

On Mon, Jun 27, 2011 at 12:53 PM, Octavian Rasnita wro=
te:
> Here is a comment that might be helpful, because it also explains why DBI=
x::Class can work with Apache::DBI (and why it is not needed):
>
> http://lists.scsys.co.uk/pipermail/dbix-class/2006-April/001 153.html
>
> ""
> DBIx::Class already manages its connections for you, and therefore it
> cannot benefit from Apache::DBI under any scenario. =A0It 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. =A0The 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. =A0Essentially, 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 =3D $DBI::connect_via;
1239 $DBI::connect_via =3D '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=3D'...

In my startup.pl (My::Model is DBIx::Class based):

$Apache::DBI::DEBUG =3D 2;
my $db_connect_params =3D 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 =3D '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:
>=20
> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
> 1238 $old_connect_via =3D $DBI::connect_via;
> 1239 $DBI::connect_via =3D 'connect';
> 1240 }

DBIx::Connector does the same thing.

> And it is also apparently not working as they expected:
>=20
> [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=3D'...
>=20
> In my startup.pl (My::Model is DBIx::Class based):
>=20
> $Apache::DBI::DEBUG =3D 2;
> my $db_connect_params =3D My::Model->connect_params;
> Apache::DBI->connect_on_init( @{$db_connect_params} );
> Apache::DBI->setPingTimeOut( $db_connect_params->[0], 5 );
>=20
> # delete this line and I will beat you with a stick (note to self)
> My::Model->connect->disconnect;
> $DBI::connect_via =3D '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/Connecto r.pm#Descripti=
on

Best,

David

Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perlfor 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/Connecto r.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.morgan@borealescapes.ca
403 288 8759

Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl foryour web application?]

On Mon, Jun 27, 2011 at 1:22 PM, David E. Wheeler wr=
ote:
> On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
>
>> Wow, that's obnoxious:
>>
>> 1237 =A0 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
>> 1238 =A0 =A0 $old_connect_via =3D $DBI::connect_via;
>> 1239 =A0 =A0 $DBI::connect_via =3D 'connect';
>> 1240 =A0 }
>
> 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:
> =A0http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Conne ctor.pm#Descr=
iption

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:
>>=20
>> =
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connecto r.pm#Descripti=
on
>>=20
>=20
> 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/Connecto r.pm#Descripti=
on
>=20
> 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_perlfor 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/Connecto r.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.morgan@borealescapes.ca
403 288 8759

Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl foryour 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

Re: Apache::DBI and DBIx::Class

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-perl, and the problem is not with Cold Fusion.

>> IMHO, worth exactly what you paid for it
This was meant to refer to my opinion, not your code, sorry.

On 27/06/11 09:38 PM, David E. Wheeler wrote:
>
> 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).

Never ran Bricolage in production. Did run a test system, ughhhhh.
I suspect the issue was with the Bricolage code, not Apache::DBI.

I have never used connect_cached, never had the need.
>
snip.....

> 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.

Postgres supports it but DBD::Pg doesn't, not with the standard DBI
fetch* APIs. At least as of last year it didn't. If I didn't have to spend
all my time reviewing and running other peoples code I would take the time
to add the functionality.

> Well, DBIx::Connector does not do connection pooling (or caching), so that wouldn't be a problem.

I am being unclear here. Each apache child/process will open 2 connections, one for
Apache::DBI and one for DBIx::Class or DBIx::Connector. Possibly more connections if
a variety of different modules are being used, each with it's own connection handling.
This explains an issue I saw with a client 2 months ago where the number of open database
sessions doubled with the introduction of some new code based on DBIx::Class.

I believed the doubling of sessions was a symptom of poor code. Neither I nor their
developers had any idea that Apache::DBI was being bypassed. Luckily it was a prototype
and the issue was caught while stress testing in their staging environment.

And so into the design and philosophy. As an admin I need to be able to deploy code without
side effects that may adversely affect other processes or the system itself.

Now at least you document your connection logic, so that if I do a quick review I can see the
implications (I doubt I would actually catch it but at least you are giving me a chance :)
whereas for DBIx::Class, if there is documentation about connecting I don't know where it is.

Even so, I believe the logic should be
if Apache::DBI use it
else use my stuff

I do not know the internals of DBI or the derived classes so I do not know if the above is
practical. However, it is respectful of the environment it is going to run in. Writing code
that specifically ignores how a system is configured is ....... impolite!

And yet Apache::DBI also has side effects. I revoke ALTER SESSION from any schema/user that will
be accessed via Apache::DBI as there will be some unaware developer who will change the
session characteristics (to get a different data format perhaps) and then will not change it
back. And so the next time the connection/handle is used the code fails. Is this his fault?
I don't believe so. It is a systems issue not a development issue.

Yeah it was a lot of fun debugging the issue that resulted in that solution :)

What I find so frustrating is that with all these magnificent tools we have now, modern
hardware, screaming fast network, Apache, perl, mod_perl, the networking libraries and
such I am still dealing with the same problems I had to deal with 10 and 15 years ago:
- let the database do the work
- do not try to configure network parameters
- close all connections (file handles, RPC, serial port, network and database)
- do not assume your code completes properly.
- do not try to manage or allocate hardware resources, just use them
- you have to share, your code is not the only thing running
- the problem is not with the tools you are using, it is your code

And it must be extremely frustrating to be a developer, have his systems people chew him
out for some problem, when he/she has not changed anything and the problem is caused by
an "impolite" library. And the database side is usually pretty good, the modules used
for SCADA are much worse.

It is inherent in the nature of perl, you have this wonderful library called CPAN,
but, how do you ensure that the modules you use do what you want and nothing more?
Do you really want to review (and understand) DateTime.pm?

And finally back to the Cold Fusion issue :
"You don't get paid to make it run on your machine,
you get paid to make it run on mine!"

I love my job, I love my job, I love my job ;)

Sorry once again,

Dave
>
>
>
> Best,
>
> David
>
>


--
Dave Morgan
Operations Manager, BorealEscapes
http://www.borealescapes.ca
dave.morgan@borealescapes.ca
403 288 8759

Re: Apache::DBI and DBIx::Class

>>>>> "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/Connecto r.pm#Description
>>

Dave> And having read that, I strongly recommend against the use of DBIx-Connector.
Dave> But then I'm just a production DBA :)

Really? I've been moving my clients *towards* it. It solves a lot of
useful problems.

I did a mashup of DBIx::Connector with SQL::Interpolate and ended up
with a very nice base class for handwritten SQL (no ORM) for a recent
project.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Apache::DBI and DBIx::Class

This is a multipart message in MIME format.
--=_alternative 00072962CA2578BE_=
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

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/Connecto r.pm#Description

>>>
>
>Dave> And having read that, I strongly recommend against the use of
DBIx-Connector.
>Dave> But then I'm just a production DBA :)
>
>Really? I've been moving my clients *towards* it. It solves a lot of
>useful problems.
>
>I did a mashup of DBIx::Connector with SQL::Interpolate and ended up
>with a very nice base class for handwritten SQL (no ORM) for a recent
>project.

Would you care to share that 'mashup' it sounds interesting
Greg
************************************************************ ************************************************************ ************************************************************ ***********
Please consider the environment before printing this e-mail.

This message is intended solely for the individual(s) and entity(s) addressed. It is confidential and may contain legally privileged information. The use, copying or distribution of this
message or any information it contains, by anyone other than the addressee, is prohibited. If you have received this message in error, please notify postmaster@orica.com. The mailbox address
from which this message has been sent is for business mail only. Mail sent to it may be subject to security scanning and delivery on non-business messages sent to this address may not occur.
Thank you.
************************************************************ ************************************************************ ************************************************************ ***********

--=_alternative 00072962CA2578BE_=
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii"

Hi Randal,







>>>

>>> You lost me. But really, I strongly recommend against the
use of Apache::DBI. Some discussion here:

>>>

>>>

>>>

>

>Dave> And having read that, I strongly recommend against the use
of DBIx-Connector.

>Dave> But then I'm just a production DBA :)

>

>Really?  I've been moving my clients *towards* it.  It solves
a lot of

>useful problems.

>

>I did a mashup of DBIx::Connector with SQL::Interpolate and ended up

>with a very nice base class for handwritten SQL (no ORM) for a recent

>project.



Would you care to share that 'mashup' it sounds interesting

Greg

***********************************************************************************************************************************************************************************************

Please consider the environment before printing this e-mail.



This message is intended solely for the individual(s) and entity(s) addressed. It is confidential and may contain legally privileged information. The use, copying or distribution of this 

message or any information it contains, by anyone other than the addressee, is prohibited. If you have received this message in error, please notify postmaster@orica.com. The mailbox address 

from which this message has been sent is for business mail only. Mail sent to it may be subject to security scanning and delivery on non-business messages sent to this address may not occur. 

Thank you.

***********************************************************************************************************************************************************************************************

Re: Apache::DBI and DBIx::Class

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 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-perl, and the problem is not with Cold Fusion.

Someone put cold fusion in your espresso. That can cause a bad day no =
question.

> >> IMHO, worth exactly what you paid for it
> This was meant to refer to my opinion, not your code, sorry.

Ah, okay.

> Never ran Bricolage in production. Did run a test system, ughhhhh.
> I suspect the issue was with the Bricolage code, not Apache::DBI.

Based on what evidence, exactly?

> I have never used connect_cached, never had the need.

If you rely on Apache::DBI, you wouldn't need connect_cached, of course.

> Postgres supports it but DBD::Pg doesn't, not with the standard DBI
> fetch* APIs. At least as of last year it didn't. If I didn't have to =
spend
> all my time reviewing and running other peoples code I would take the =
time
> to add the functionality.

What's wrong with SQL? Example:

#!/usr/local/bin/perl -w

use v5.14;
use utf8;
use DBI;

my $dbh =3D DBI->connect(
'dbi:Pg:dbname=3Dtry', '', '', {
PrintError =3D> 0,
RaiseError =3D> 1,
AutoCommit =3D> 1,
pg_enable_utf8 =3D> 1,
pg_server_prepare =3D> 0,
}
);

$dbh->begin_work;
$dbh->do('CREATE TABLE foo (id INT)');
$dbh->do('INSERT INTO foo VALUES (1), (2), (3), (4), (5), (6)');

$dbh->do('DECLARE getfoo CURSOR FOR SELECT id FROM foo');

my $sth =3D $dbh->prepare('FETCH FORWARD 2 FROM getfoo');
for (1..3) {
say $_;
$sth->execute;
while (my $r =3D $sth->fetch) {
say ".. $r->[0]";
}
}
$dbh->rollback;

Output:

1
.. 1
.. 2
2
.. 3
.. 4
3
.. 5
.. 6

>> Well, DBIx::Connector does not do connection pooling (or caching), so =
that wouldn't be a problem.
>=20
> I am being unclear here. Each apache child/process will open 2 =
connections, one for
> Apache::DBI and one for DBIx::Class or DBIx::Connector.

DBIx::Connector disables Apache::DBI, so there should only be one. If =
not, there's a bug. Also, most folks who use DBIx::Connector don't use =
Apache::DBI at all.

> Possibly more connections if
> a variety of different modules are being used, each with it's own =
connection handling.

Yes, that's a risk. Don't do that.

> This explains an issue I saw with a client 2 months ago where the =
number of open database
> sessions doubled with the introduction of some new code based on =
DBIx::Class.

Sounds like a bug in DBIx::Class.

> I believed the doubling of sessions was a symptom of poor code. =
Neither I nor their
> developers had any idea that Apache::DBI was being bypassed. Luckily =
it was a prototype
> and the issue was caught while stress testing in their staging =
environment.

Yes, DBIx::Class should disable Apache::DBI when it does its connecting, =
just like DBIx::Connector does. Apache::DBI should still be usable if =
you're connecting by some means other than DBIx::Class. But this is one =
of the three raisons d'=EAtre for DBIx::Connector: Use it to connect =
instead of the DBI and do your own connection caching. I believe =
DBIx::Class will be switching to DBIx::Connector eventually.

> And so into the design and philosophy. As an admin I need to be able =
to deploy code without
> side effects that may adversely affect other processes or the system =
itself.

Yeah, that's exactly the complaint about Apache::DBI. Its entire purpose =
is side-effects.

> Now at least you document your connection logic, so that if I do a =
quick review I can see the
> implications (I doubt I would actually catch it but at least you are =
giving me a chance :)
> whereas for DBIx::Class, if there is documentation about connecting I =
don't know where it is.

Yeah, I had to do some mining to dig it out for DBIx::Connector.

> Even so, I believe the logic should be
> if Apache::DBI use it
> else use my stuff

IIRC, I can't use Apache::DBI and still support the ability to reconnect =
when a database connection has dropped. That's its second raison d'=EAtre =
(pings mostly go away when you use it in fixup mode, which is =
recommended).

> I do not know the internals of DBI or the derived classes so I do not =
know if the above is
> practical. However, it is respectful of the environment it is going to =
run in. Writing code
> that specifically ignores how a system is configured is ....... =
impolite!

Well, one could interpret Apache::DBI as doing exactly the same thing. =
Someone loads it unbeknownst to you, and all of a sudden the behavior of =
DBI->connect is globally changed.

> And yet Apache::DBI also has side effects. I revoke ALTER SESSION from =
any schema/user that will
> be accessed via Apache::DBI as there will be some unaware developer =
who will change the
> session characteristics (to get a different data format perhaps) and =
then will not change it
> back. And so the next time the connection/handle is used the code =
fails. Is this his fault?
> I don't believe so. It is a systems issue not a development issue.

Right, but this is why DBIx::Connector doesn't do connection caching =
itself. The developer controls the scope in which it lives, and it =
DBIx::Connector just worries about keeping a solid connection across =
forks and threads and disconnects.

> Yeah it was a lot of fun debugging the issue that resulted in that =
solution :)

I think it would've been more straight-forward if Apache::DBI had never =
been used at all.

> What I find so frustrating is that with all these magnificent tools we =
have now, modern
> hardware, screaming fast network, Apache, perl, mod_perl, the =
networking libraries and
> such I am still dealing with the same problems I had to deal with 10 =
and 15 years ago:
> - let the database do the work
> - do not try to configure network parameters
> - close all connections (file handles, RPC, serial port, network =
and database)
> - do not assume your code completes properly.
> - do not try to manage or allocate hardware resources, just use =
them
> - you have to share, your code is not the only thing running
> - the problem is not with the tools you are using, it is your =
code

Amen.

> And it must be extremely frustrating to be a developer, have his =
systems people chew him
> out for some problem, when he/she has not changed anything and the =
problem is caused by
> an "impolite" library. And the database side is usually pretty good, =
the modules used
> for SCADA are much worse.

Yeah, this describes the problem with Apache::DBI quite nicely. =
Action-at-a-distance and all that.

> It is inherent in the nature of perl, you have this wonderful library =
called CPAN,
> but, how do you ensure that the modules you use do what you want and =
nothing more?
> Do you really want to review (and understand) DateTime.pm?
>=20
> And finally back to the Cold Fusion issue :
> "You don't get paid to make it run on your machine,
> you get paid to make it run on mine!"
>=20
> I love my job, I love my job, I love my job ;)
>=20
> Sorry once again,

No worries. Think I'll not contribute to this thread anymore, though, as =
we're veering pretty far off-topic. Hope the points are of interest to =
others, and historically relevant going forward, but I don't think I =
could add much more. And I'm happy to agree to disagree and go back to =
work.

Best,

David