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