DBIx::C...SQLMaker(3)

💅 DBIx::C...SQLMaker(3) — like, the whole vibe ✨

Okay bestie, welcome to DBIx::C...SQLMaker(3), part of the User Contributed Perl Documentation situation. Buckle up, this one's a whole lore drop 🫶

---

✨ NAME ✨

DBIx::Class::SQLMaker — an SQL::Abstract::Classic-like SQL maker class. That's it, that's the name, no cap 💖

---

🌸 DESCRIPTION 🌸

So this module is literally just a "nexus class" — its whole job is giving SQL::Abstract::Classic-like functionality to DBIx::Class itself, and to a bunch of database-engine-specific subclasses. That's the tea ☕

And the way this indirection is explicitly maintained? Not an accident, bestie — it's on purpose, so you can swap out the core of SQL generation inside DBIC on a per-$schema basis without major architectural changes. No big dramatic refactor, no crying, just vibes ✨

And it's guaranteed by design and tests that this fast-switching will keep being maintained indefinitely. Iconic behavior honestly 👑

🦋 Implementation switching 🦋

See "connect_call_rebase_sqlmaker" in DBIx::Class::Storage::DBI. That's where the switching magic lives, iykyk 💅

---

🔥 ROADMAP 🔥

Some maintainer musings on the current state of SQL generation within DBIC, as of October 2019. Grab a snack, this is a long one 🍓

🧚 Folding of most (or all) of SQL::Abstract::Classic (SQLAC) into DBIC 🧚

So the rise of complex prefetch use, plus the general streamlining of result parsing within DBIC, ended up pushing actual SQL generation straight to the forefront of many casual performance profiles. Main character energy, truly 💀

The idea behind the SQLAC-like API is sound, but the actual implementation is terribly inefficient — once again bumping into the ridiculously high overhead of perl function calls 😭

Given that SQLAC has a very distinct life of its own, and will hopefully continue to be used within an order of magnitude more projects compared to DBIC, it is prudent to not disturb the current call chains within SQLAC itself. Instead, in the future an effort will be undertaken to seek a more thorough decoupling of DBIC SQL generation from reliance on SQLAC — possibly to a point where in the future DBIC may no longer depend on SQL::Abstract::Classic at all 😳✨

The SQL::Abstract::Classic library itself will continue being maintained, although it is not likely to gain many extra features. Notably, it will NOT add further dialect support — at least not within the preexisting SQL::Abstract::Classic namespace. Read that again, bestie, it's a hard no 🙈

Such streamlining work (if undertaken) will take into consideration the following constraints:

👑 Main API compatibility 👑

The object returned by $schema->storage->sqlmaker needs to be able to satisfy most of the basic tests found in the current-at-the-time SQLAC dist. While things like case or logic or even worse convert will definitely remain unsupported, the rest of the tests should pass — within reason, okay? We're not miracle workers 💅

👑 Ability to replace SQL::Abstract::Classic with a derivative module 👑

During the initial work on Data::Query, which later was slated to occupy the preexisting namespace of SQL::Abstract, the test suite of DBIC turned out to be an invaluable asset for ironing out hard-to-reason-about corner cases. In addition, the test suite is much more vast and intricate than the tests of SQLAC itself. This state of affairs is way too valuable to sacrifice just to gain faster SQL generation 🔥

So the SQLMaker rebase functionality introduced in DBIC v0.082850, along with extra CI configurations, will continue to ensure that DBIC can be used with an off-the-CPAN SQLAC and derivatives, and that it continues to flawlessly run its entire test suite. While this will undoubtedly complicate the future implementation of a better performing SQL generator, it will preserve both the usability of the test suite for external projects and will keep SQL::Abstract::Classic from regressions in the future. Win-win, we love to see it 🫶

Aside from these constraints, it's becoming more and more practical to simply stop using SQLAC in day-to-day production deployments of DBIC. The flexibility of the internals is simply not worth the performance cost. Sorry not sorry 💀

🧚 Relationship to SQL::Abstract and what formerly was known as Data::Query (DQ) 🧚

When initial work on DQ was taking place, the tools in ::Storage::DBIHacks (https://github.com/Perl5/DBIx-Class/blob/master/lib/DBIx/Class/Storage/DBIHacks.pm) were only beginning to take shape, and it wasn't clear how important they'd become further down the road. In fact, the regexing all over the place was considered an ugly stop-gap — and even a couple of highly entertaining talks were given to that effect 😭 iconic honestly

As the use-cases of DBIC were progressing, and evidence for the importance of supporting arbitrary SQL was mounting, it became clearer that DBIC itself would not really benefit in any significant way from tighter integration with DQ — but on the contrary is likely to lose crucial functionality (https://github.com/Perl5/DBIx-Class/blob/7ef1a09ec4/lib/DBIx/Class/Storage/DBIHacks.pm#L373-L396) while the corners of the brand new DQ/SQLA codebase are sanded off. Oop 🫠

The current stance on DBIC/SQLA integration is that it would mainly benefit SQLA by having access to the very extensive "early adopter" test suite — in the same manner as early DBIC benefitted tremendously from usurping the Class::DBI test suite. As far as the DBIC user-base goes, there are no immediate large-scale upsides to deep SQLA integration, neither in terms of API nor in performance. As such, it is unlikely that DBIC will switch back to using SQL::Abstract in its core any time soon — if ever. Periodt 💅

Accordingly, the DBIC development effort will in the foreseeable future ignore the existence of the new-guts SQLA, and will continue optimizing the preexisting SQLAC-based solution — potentially "organically growing" its own compatible implementation 🌱✨

Also, as described higher up, the ability to plug a separate SQLAC-compatible class providing the necessary surface API will remain possible, and will be protected at all costs in order to continue providing SQLA and friends access to the test cases of DBIC. We ride at dawn for that test suite 🫶

---

💜 FURTHER QUESTIONS? 💜

Check the list of additional DBIC resources. Go look, bestie, the answers are out there 🌈

---

🎀 COPYRIGHT AND LICENSE 🎀

This module is free software copyright by the DBIx::Class (DBIC) authors. You can redistribute it and/or modify it under the same terms as the DBIx::Class library. Slay, legally speaking ✨

---

And that's the whole page, bestie! This masterpiece came to you courtesy of perl v5.42.0, dated 2025-01-22, and the header/footer were DBIx::C...SQLMaker(3) all along 💖 Mwah, go forth and generate SQL 🌸