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
[email protected]
403 288 8759
