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.mor...@borealescapes.ca 403 288 8759