I have tried Class::DBI before. That’s a rant for another time.

Briefly: I initially thought it was great. But when I started wanting to do the slightly more complex things that are possible with SQL, I ran into trouble; anything that involves multiple joins, f.ex., is at best difficult to express. I instead frequently found myself grepping and mapping through lists of result objects; which is just a waste. SQL can express the same things more directly, and I can avoid a whole lot of database roundtrips as well as oodles of object construction that happens in the Class::DBI guts. By writing the SQL myself I can write a single query that gives me exactly the results I need for almost anything. Class::DBI hits the database much harder and makes it shovel a lot more data back to the application for the same effect.

I really wanted to like Class::DBI; but if you actually use your database relationally, it gets in the way too much.

Instead, I found myself much more productive by writing higher-level abstractions than what Class::DBI can give me, but tailored to my particular needs. Eg. I have standardised on particular naming conventions for the POST parameters in my CGI scripts, and I wrote a generic CRUD function that uses these conventions, along with a caller-supplied list of field names, to do almost all of the CRUD stuff in my app. Whether this one function encapsulates a Class::DBI hierarchy or is written using uncircumphrased SQL queries really doesn’t make a lot of difference, but its existence has greatly reduced the amount of code I wrote elsewhere.

In other words, I’ve found that for me, Class::DBI abstracts away the wrong things and actually makes the right ones harder.

Okay, so this managed to turn into a long rant anyway… and I haven’t even explained what it is that Class::DBI does so badly. I guess there’ll be another root node coming sometime in the next while.

Makeshifts last the longest.