DBIx::Class::SQLMaker - An SQL::Abstract::Classic-like SQL maker class

       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)

       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.

   Implementationswitching
       See "connect_call_rebase_sqlmaker" in DBIx::Class::Storage::DBI

       Check the list of additional DBIC resources.

       DBIx::Class::SQLMaker - An SQL::Abstract::Classic-like SQL maker class

       Some maintainer musings on the current state of SQL generation within DBIC as of October 2019

   Foldingofmost(orall)ofSQL::Abstract::Classic(SQLAC)intoDBIC.
       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 inthefutureDBICmaynolongerdependonSQL::Abstract::Classic at all.

       TheSQL::Abstract::Classiclibraryitselfwillcontinuebeingmaintained 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.

   RelationshiptoSQL::AbstractandwhatformerlywasknownasData::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
       regexingallovertheplace 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.