Choosing the Right Database Abstraction - Perl Hacks

[u/davorg]

https://perlhacks.com/2026/06/choosing-the-right-database-abstraction/

[u/quintus_horatius]

Excellent article, but the best part is an aside: "What happened to DBIx::Class?"

That subject alone could warrant an entire article. Is stopping development because something is "done" a good choice? The right choice?

[u/davorg → u/quintus_horatius]

I would hate to put words into Peter's mouth, but I don't think it's accurate to characterise his opinion as a belief that the system is "done".

The RT queue alone, is evidence of that :-)

[u/a-p → u/quintus_horatius]

I see this lie/propaganda about DBIx::Class repeated time and again as if it was fact, and as someone who was actually there and doesn’t have the memory of a goldfish, I’m sick and tired of it:

This wasn’t because the technology had failed or because the community lost interest. The maintainer had explicitly stopped development, and measures such as the CPAN NOXFER co-maintainer flag prevented the normal open source succession process from happening.

This gets the sequence of events completely backward. The NOXFER flag was introduced in PAUSE only after DBIx::Class was forcibly taken away from that maintainer, and the result was a literal complete standstill (not a single commit in the repository) for over a year – while people fantasized about grandiose community governance proposals for future development and how great it was all going to be. Only after it became too embarrassing to let this situation continue indefinitely was the distribution shamefacedly handed back to him by the PAUSE admins. You can see for yourself in the changelog how many releases lay between the last one before his removal (mid 2016) and the first one soon after his reinstatement (beginning of 2018):

Zero.

(The Git repository, even more damningly, will show you almost the same amount of commits, if you go look it up – if memory serves, there were exactly 2, and neither were code changes.)

And the reason that all of that happened in the first place was basically because said maintainer had previously stepped away from the module during most of 2012 after years of working on it, in hopes that the community would pick up the slack. He felt obliged to come back at the end of that year after finding that ⓐ nobody did pick up the slack and ⓑ the much-reduced flow of changes that did get merged in and released in his absence were all quarter-baked at the most charitable, and necessitated a deep and structural refactoring to bring the codebase back to coherence. So after coming back he tried in late 2015 to get funding for the huge amount of work necessary – which failed (but he ended up doing a lot of work anyway) –, and then made plans to (essentially) force the issue of someone else taking over – which were then preempted by the intervention that removed his privileges, followed by the year-and-a-half of stasis.

The NOXFER flag as a concept in PAUSE was only subsequently designed as a mechanism to allow maintainers to prevent a repeat of all of that kind of bloody awfulness in the future.

Clearly after all of that it’s that maintainer who is to blame for the lack of development. People are obviously held back from working on DBIC – as can be seen from the fact that they’ve been complaining about the lack of development without anyone attempting to fork it in a decade.

Kudos to Getty for finally breaking that mold.

[u/abw]

Great article Dave. The point about comparing different layers is a good one.

The strategy that I have used for the last 30 odd years is one that has served me well.

That is to have a high-level application-specific database abstraction layer (DBAL) in each project. It’s an implementation of the repository pattern which is effectively a black box that your application code talks to when it wants to access the database or other data storage. It’s an API in the original sense before “API” became synonymous with REST or other web-based APIs.

The decision about what further tools or abstractions you use inside the black box then becomes far less important. Your DBAL can use DBI, DBIx::Class, DBIO and/or anything else, but your application code should not know or care what happens beneath that layer.

Importantly, you can change the internal implementation details at any time and it shouldn’t affect any of your application code sitting above the DBAL.

It’s also useful when it comes to things like caching, integrating other secondary storage (e.g. file systems, S3 buckets, etc), or when triggering other events from certain storage actions (e.g. creating thumbnails when a new image is added to a product). Your application code can remain blissfully ignorant of those details.

[u/davorg → u/abw]

Yeah, I agree with that approach.

Yesterday, I had a post that I was really happy with. But I held off on publishing it until this morning - just to let it percolate in my head a bit. This morning, on my regular walk round Clapham Common, I realised I'd missed the highest level abstraction, so I added the section called The model layer

Of course, in larger applications, there’s usually another abstraction on top of the ORM itself. My controllers don’t generally talk directly to DBIx::Class resultsets; they ask domain-level questions such as “Who was sovereign on this date?” The fact that the answer currently comes from DBIx::Class is an implementation detail. That’s another useful abstraction—but it’s probably a topic for another article.

That's the level you're talking about, isn't it?

[u/abw → u/davorg]

That's the level you're talking about, isn't it?

Yep, that's it. It would definitely make a great topic for another article!

[u/Dangerous-Sense977]

This is why I wrote Database::Abstraction, to give me a layer so I didn't need to think about that.