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.