DBIx::Class::SQLMaker - An SQL::Abstract-based SQL maker class
This module is currently a subclass of SQL::Abstract and includes a number of DBIC-specific extensions/workarounds, not suitable for inclusion into the SQL::Abstract core. It also provides all (and more than) the functionality of SQL::Abstract::Limit, see DBIx::Class::SQLMaker::LimitDialects for more info.
Currently the enhancements over SQL::Abstract are:
Support for JOIN statements (via extended table/from support)
JOIN
table/from
Support of functions in SELECT lists
SELECT
GROUP BY/HAVING support (via extensions to the order_by parameter)
GROUP BY
HAVING
A rudimentary multicolumn IN operator
Support of ...FOR UPDATE type of select statement modifiers
...FOR UPDATE
Some maintainer musings on the current state of SQL generation within DBIC as of Oct 2015
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 SQLA's API is sound, the actual implementation is terribly inefficient (once again bumping into the ridiculously high overhead of perl function calls).
Given that SQLA has a very distinct life on its own, and is used within an order of magnitude more projects compared to DBIC, it is prudent to not disturb the current call chains within SQLA itself. Instead in the near future an effort will be undertaken to seek a more thorough decoupling of DBIC SQL generation from reliance on SQLA, possibly to a point where DBIC will no longer depend on SQLA at all.
The SQL::Abstract library itself will continue being maintained although it is not likely to gain many extra features, notably dialect support, at least not within the base SQL::Abstract namespace.
SQL::Abstract
This work (if undertaken) will take into consideration the following constraints:
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 SQLA dist. While things like case or logic or even worse convert will definitely remain unsupported, the rest of the tests should pass (within reason).
$schema->storage->sqlmaker
During the initial work on Data::Query 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 SQLA itself. This state of affairs is way too valuable to sacrifice in order to gain faster SQL generation. Thus a compile-time-ENV-check will be introduced along with an extra CI configuration to ensure that DBIC is used with an off-the-CPAN SQLA and that it continues to flawlessly run its entire test suite. While this will undoubtedly complicate the implementation of the better performing SQL generator, it will preserve both the usability of the test suite for external projects and will keep SQL::Abstract from regressions in the future.
Aside from these constraints it is becoming more and more practical to simply stop using SQLA in day-to-day production deployments of DBIC. The flexibility of the internals is simply not worth the performance cost.
When initial work on DQ was taking place, the tools in ::Storage::DBIHacks 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 way from an integration with DQ, but on the contrary is likely to lose functionality while the corners of the brand new DQ codebase are sanded off.
The current status of DBIC/DQ integration is that the only benefit is for DQ 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 practical upsides to DQ integration, neither in terms of API nor in performance.
So (as described higher up) the DBIC development effort will in the foreseable future ignore the existence of DQ, and will continue optimizing the preexisting SQLA-based solution, potentially "organically growing" its own compatible implementation. Also (again, as described higher up) the ability to plug a separate SQLA-compatible class providing the necessary surface API will remain possible, and will be protected at all costs in order to continue providing DQ access to the test cases of DBIC.
In the short term, after one more pass over the ResultSet internals is undertaken real soon now (tm), and before the SQLA/SQLMaker integration takes place, the preexisting DQ-based branches will be pulled/modified/rebased to get up-to-date with the current state of the codebase, which changed very substantially since the last migration effort, especially in the SQL classification meta-parsing codepath.
is_literal_value, is_plain_value
FETCH_CODE_ATTRIBUTES, MODIFY_CODE_ATTRIBUTES, VALID_DBIC_CODE_ATTRIBUTE
Check the list of additional DBIC resources.
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.
To install DBIx::Class, copy and paste the appropriate command in to your terminal.
cpanm
cpanm DBIx::Class
CPAN shell
perl -MCPAN -e shell install DBIx::Class
For more information on module installation, please visit the detailed CPAN module installation guide.