1DBIx::Class::SQLMaker(3U)ser Contributed Perl DocumentatiDoBnIx::Class::SQLMaker(3)
2
3
4

NAME

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

DESCRIPTION

9       This module serves as a mere "nexus class" providing
10       SQL::Abstract::Classic-like functionality to DBIx::Class itself, and to
11       a number of database-engine-specific subclasses. This indirection is
12       explicitly maintained in order to allow swapping out the core of SQL
13       generation within DBIC on per-$schema basis without major architectural
14       changes. It is guaranteed by design and tests that this fast-switching
15       will continue being maintained indefinitely.
16
17   Implementation switching
18       See "connect_call_rebase_sqlmaker" in DBIx::Class::Storage::DBI
19

ROADMAP

21       Some maintainer musings on the current state of SQL generation within
22       DBIC as of October 2019
23
24   Folding of most (or all) of SQL::Abstract::Classic (SQLAC) into DBIC.
25       The rise of complex prefetch use, and the general streamlining of
26       result parsing within DBIC ended up pushing the actual SQL generation
27       to the forefront of many casual performance profiles. While the idea
28       behind the SQLAC-like API is sound, the actual implementation is
29       terribly inefficient (once again bumping into the ridiculously high
30       overhead of perl function calls).
31
32       Given that SQLAC has a very distinct life on its own, and will
33       hopefully continue to be used within an order of magnitude more
34       projects compared to DBIC, it is prudent to not disturb the current
35       call chains within SQLAC itself. Instead in the future an effort will
36       be undertaken to seek a more thorough decoupling of DBIC SQL generation
37       from reliance on SQLAC, possibly to a point where in the future DBIC
38       may no longer depend on SQL::Abstract::Classic at all.
39
40       The SQL::Abstract::Classic library itself will continue being
41       maintained although it is not likely to gain many extra features,
42       notably it will NOT add further dialect support, at least not within
43       the preexisting "SQL::Abstract::Classic" namespace.
44
45       Such streamlining work (if undertaken) will take into consideration the
46       following constraints:
47
48       Main API compatibility
49           The object returned by "$schema->storage->sqlmaker" needs to be
50           able to satisfy most of the basic tests found in the current-at-
51           the-time SQLAC dist.  While things like case or logic or even worse
52           convert will definitely remain unsupported, the rest of the tests
53           should pass (within reason).
54
55       Ability to replace SQL::Abstract::Classic with a derivative module
56           During the initial work on Data::Query, which later was slated to
57           occupy the preexisting namespace of SQL::Abstract, the test suite
58           of DBIC turned out to be an invaluable asset to iron out hard-to-
59           reason-about corner cases.  In addition the test suite is much more
60           vast and intricate than the tests of SQLAC itself. This state of
61           affairs is way too valuable to sacrifice in order to gain faster
62           SQL generation. Thus the SQLMaker rebase functionality introduced
63           in DBIC v0.082850 along with extra CI configurations will continue
64           to ensure that DBIC can be used with an off-the-CPAN SQLAC and
65           derivatives, and that it continues to flawlessly run its entire
66           test suite.  While this will undoubtedly complicate the future
67           implementation of a better performing SQL generator, it will
68           preserve both the usability of the test suite for external projects
69           and will keep SQL::Abstract::Classic from regressions in the
70           future.
71
72       Aside from these constraints it is becoming more and more practical to
73       simply stop using SQLAC in day-to-day production deployments of DBIC.
74       The flexibility of the internals is simply not worth the performance
75       cost.
76
77   Relationship to SQL::Abstract and what formerly was known as Data::Query
78       (DQ)
79       When initial work on DQ was taking place, the tools in
80       ::Storage::DBIHacks
81        <https://github.com/Perl5/DBIx-
82       Class/blob/master/lib/DBIx/Class/Storage/DBIHacks.pm> were only
83       beginning to take shape, and it wasn't clear how important they will
84       become further down the road. In fact the regexing all over the place
85       was considered an ugly stop-gap, and even a couple of highly
86       entertaining talks were given to that effect. As the use-cases of DBIC
87       were progressing, and evidence for the importance of supporting
88       arbitrary SQL was mounting, it became clearer that DBIC itself would
89       not really benefit in any significant way from tigher integration with
90       DQ, but on the contrary is likely to lose crucial functionality
91       <https://github.com/Perl5/DBIx-
92       Class/blob/7ef1a09ec4/lib/DBIx/Class/Storage/DBIHacks.pm#L373-L396>
93       while the corners of the brand new DQ/SQLA codebase are sanded off.
94
95       The current stance on DBIC/SQLA integration is that it would mainly
96       benefit SQLA by having access to the very extensive "early adopter"
97       test suite, in the same manner as early DBIC benefitted tremendously
98       from usurping the Class::DBI test suite. As far as the DBIC user-base -
99       there are no immediate large-scale upsides to deep SQLA integration,
100       neither in terms of API nor in performance.  As such it is unlikely
101       that DBIC will switch back to using SQL::Abstract in its core any time
102       soon, if ever.
103
104       Accordingly the DBIC development effort will in the foreseable future
105       ignore the existence of the new-guts SQLA, and will continue optimizing
106       the preexisting SQLAC-based solution, potentially "organically growing"
107       its own compatible implementation. Also, as described higher up, the
108       ability to plug a separate SQLAC-compatible class providing the
109       necessary surface API will remain possible, and will be protected at
110       all costs in order to continue providing SQLA and friends access to the
111       test cases of DBIC.
112

FURTHER QUESTIONS?

114       Check the list of additional DBIC resources.
115
117       This module is free software copyright by the DBIx::Class (DBIC)
118       authors. You can redistribute it and/or modify it under the same terms
119       as the DBIx::Class library.
120
121
122
123perl v5.38.0                      2023-07-20          DBIx::Class::SQLMaker(3)
Impressum