Provided by: libdbix-class-perl_0.082844-1_all 
NAME
DBIx::Class::SQLMaker - An SQL::Abstract::Classic-like SQL maker class
DESCRIPTION
This module serves as a mere "nexus class" providing SQL::Abstract::Classic-like functionality to
DBIx::Class itself, and to a number of database-engine-specific subclasses. This indirection is
explicitly maintained in order to allow swapping out the core of SQL generation within DBIC on
per-$schema basis without major architectural changes. It is guaranteed by design and tests that this
fast-switching will continue being maintained indefinitely.
Implementation switching
See "connect_call_rebase_sqlmaker" in DBIx::Class::Storage::DBI
ROADMAP
Some maintainer musings on the current state of SQL generation within DBIC as of October 2019
Folding of most (or all) of SQL::Abstract::Classic (SQLAC) into DBIC.
The rise of complex prefetch use, and the general streamlining of result parsing within DBIC ended up
pushing the actual SQL generation to the forefront of many casual performance profiles. While the idea
behind the SQLAC-like API is sound, 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 on 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.
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).
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 to iron 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 in order to gain faster SQL
generation. Thus 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.
Aside from these constraints it is 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.
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 will 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. 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 tigher 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.
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 - 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.
Accordingly the DBIC development effort will in the foreseable 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.
FURTHER QUESTIONS?
Check the list of additional DBIC resources.
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.
perl v5.40.0 2025-02-01 DBIx::Class::SQLMaker(3pm)