Sure, I use selectall_arrayref( $sql, { Slice => {} }, $foo, $bar, $baz ) most of the time. Which is longwinded. And the Slice => {} bit constantly chafes me. And often enough I only need one row, or I need a completely flat list made up of all rows. I can either standardise on one longwinded method and litter my code with repetitve data structure munging, or I need to keep using different methods that follow an extremly unhelpful naming convention.

Or I can use someone else’s code which is standardised on one method and does the data munging for me.

Really, I made an effort to work with just plain DBI. I didn’t declare it too low-level from the get go or some such notion, which I’ve seen occasionally. I did in fact not expect to have to use anything else on top. And it is indeed very close to being perfectly adequate. If a new release of DBI offers DBIx::Simplesque result fetching methods in addition to its current set, I’ll gladly go back to vanilla DBI.

But in the meantime I need to be able to look at my code and see what’s going on without having to stop and think hard for a third of a second at every other method, or I’ll never get anything done.

Makeshifts last the longest.

But in the meantime I need to be able to look at my code and see what’s going on without having to stop and think hard for a third of a second at every other method, or I’ll never get anything done.

It sounds like your code is too DWIS instead of DWIM. Your top-level code should just be do_this, do_that which no hint of what model is doing what for you.

In theory, that would be enough. In practice someone has to write that do_this, do_that toplevel code as well. :-) (That is exactly what I’m doing, FWIW. If I had the choice of PostgreSQL, I’d in fact be writing stored procedures.)

Makeshifts last the longest.