|The stupid question is the question not asked|
[Note: I considered posting this in the Module Reviews, but decided against doing so because itís a comparison of multiple modules, which does not seem to fit the format of that section.]
Initially, I purposely avoided using any helper or abstractor modules on top of DBI, because I wanted to see what real problems I would encounter with its use Ė if any. After a couple of projects with it under my belt, I can say I have: Iím going crosseyed at all the (select|fetch)(all|row|col)_(array|hash)(ref)? methods in my code (some of them additionally modulated by passing an empty hash to indicate that I want an AoH rather than an AoA). I have been fighting with an increasingly uncomfortable feeling of programming by coincidence because I can never tell at a glance what data structure any piece of my code will return. Itís killing my productivity because Iíve lost my confidence and I keep getting jarred out of the flow.
So I struck out to find what DBIx::* modules from the CPAN might be applicable, and to evaluate how well theyíd address this particular need of mine.
Most of the modules that made it into my first broad selection have a very different focus. Closest among the differently-focussed modules are DBIx::DWIW and DBIx::Easy, which were in the race until the penultimate round. Those mainly allow you to avoid some of the more menial SQL labouring, but they come up short in terms of options for simplified fetching of results. Since I already have a lot of SQL queries written, and because the things I ask of my databases are usually not complicated, but still non-trivial, I do not stand to gain much from the major offerings of these modules.
Thus, the last two modules standing were DBIx::ContextualFetch and DBIx::Simple. In this shootout, DBIx::ContextualFetch clearly loses. It does not address fetching results as flattened structures at all, and all of its handful of methods have quite similar names, much like in DBI. Its main aim seems to be to keep with DBI tradition. In contrast, DBIx::Simple offers methods for pulling out query results in every possible data structure you might prefer, and the methods are named distinctly and memorably, with a natural and consistent scheme for distinguishing between fetching only one row or all of them. It is exactly what I need.
Itís additionally nice for integrating SQL::Abstract, DBIx::XHTML_Table and Text::Table smoothly, without putting any pressure on the user to buy into these modules. I have no need for DBIx::XHTML_Table or Text::Table right now, and I currently avoid SQL::Abstract, since I ran into limitations with it in the past. But should its limitations be adequately addressed in a future version, or should I have a need for what the other modules offer, then I have a very easy growth vector. Thatís quite cool, and reflects the same virtues as Perl itself or other great modules like the Template Toolkit.
Overall, after my survey of the landscape of DBI usability layer modules on CPAN, I look forward to spending more time with DBIx::Simple. Only experience will show if it actually delivers on its promises, of course, but I am quite positive about that.
Makeshifts last the longest.