1DBIx::Class::SQLMaker(3U)ser Contributed Perl DocumentatiDoBnIx::Class::SQLMaker(3)
2
6 DBIx::Class::SQLMaker - An SQL::Abstract::Classic-like SQL maker class
7
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 Implementation switching
18 See "connect_call_rebase_sqlmaker" in DBIx::Class::Storage::DBI
19
21 Some maintainer musings on the current state of SQL generation within
22 DBIC as of October 2019
23 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 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 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 Such streamlining work (if undertaken) will take into consideration the
46 following constraints:
47 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 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 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 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 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 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
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.
120perl v5.32.0 2020-07-28 DBIx::Class::SQLMaker(3)