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
