After about two years of working with Perl I had an epiphany: the primary reason Perl was often the best tool for a job was the tremendously large, tremendously high quality module library on CPAN. To get really good at what I do, then, it pays to make the fullest use of this module library.
I learned a lot of things at YAPC this summer from Jesse Vincent's RT talk. Besides things specific to RT, I learned about two classes of modules I needed to look into. The first was HTML templating systems. As anyone who's done any reading on the subject knows, templating systems are a dime a dozen. There are so many of them because they solve a very common set of problems, and everyone reinvents the wheel to solve that problem before they discover preexisting alternatives. RT uses HTML::Mason. I realized I should probably never make another web application without using HTML::Mason or a templating system. But I've been cheating, and never got around to learning them.
Like templating systems, DBIx::Recordset solves a recurring problem in DBI: building SELECT statements. Jesse mentioned RT had its own query builder called DBIx::SearchBuilder, but commented that if he had had it to do over again, he probably would have just used DBIx::Recordset rather than reinventing the wheel. I resolved also to look into these modules to see what the hoopla was about. Generally speaking, I like to follow where really smart people lead; when I see that "everyone" seems to be using templating systems and query builders, especially people I respect, I start to suspect I should use them, too.
DBIx::Recordset is a bit controversial. perl.com had an article supporting DBIx::Recordset vs. straight DBI, followed by an article supporting straight DBI vs. DBIx::Recordset. Smart people, I think, wouldn't just assume everything is black and white but instead consider the points raised in both articles so they can make the best selection of tools for a particular job. For my part, I've not yet finished reading either artcile, but I agree with the second that the concerns about table mutation raised in the first are overstated. Nevertheless, I still suspect there's something useful in DBIx::Recordset and the other modules that solve the same set of problems.
Which brings me to my question. I was thinking I heard of another module or two besides DBIx::Recordset and DBIx::SearchBuilder that work in this problem space. Did I dream that? If not, what are they? I'm searching through the DBIx namespace in my MINICPAN, but have trouble knowing what everything is for. (There's some other interesting tools there, though, such as a class to represent complete database schemas. This is fun and educational, if nothing else.)
The pro-DBI article mentions "Tangram" as another alternative.
The syntax for DBIx::Recordset looks less fun than beating my brains out with a brick. I'd rather start with the code examples given in the pro-DBI article, wrap it in functions, and make my own library. Anything that returns globs instead of objects is not intuitive to me, and I still haven't figured out what all those exclamation points are for.
Re:Update
chromatic on 2002-12-20T21:14:58
I wouldn't characterize the "pro-DBI" article as being "con-DBIx::Recordset". Rather, I thought some of the claims of the first article were overstated. Then again, I prefer not to pull out the Big Stick of Abstraction +1 until I know I'm fighting something hairier than a sewer rat.
Wow, that was almost quotable.
Re:Update
jdavidb on 2002-12-20T22:01:13
Yes, it's definitely not con-DBIx::Recordset. It states at the beginning, then end, and through the middle that DBIx::Recordset is a useful tool that can often serve a purpose. I didn't intend to imply it was anything else.
Dave Rolsky has put together a document[1] with features of all the major object-relational mapping and object-oriented persistence modules on CPAN. It's required reading if you're doing exploration in this area.
[1] POOP Comparison
