From: Peter Rabbitson <ribasushi@cpan.org>
Date: Fri, 26 Feb 2016 08:57:27 +0000 (+0100)
Subject: Switch the main dev branch back to 'master'
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=33d0570dfd94fa18878641cb054e981c04f40e26;p=dbsrgits%2FDBIx-Class-Historic.git

Switch the main dev branch back to 'master'

Previously the idea was to have two dev branches - one for "the crowd", and
another one for the rel manager to do periodic squashes, merges, cleanups etc.
This worked rather well for about 1.5 years, but with the primary architect
outgoing it can't be sustained, and only serves to confuse everyone.

Thus a fast forward with a mini-merge of master up to the tip of current/blead
and continuing pushes to master alone from there on. Not yet deleting the old
'current/blead' and 'current/for_cpan_index' branches, as it affects PR states
due to useless "smarts" in the github logic.
---

33d0570dfd94fa18878641cb054e981c04f40e26
diff --cc .travis.yml
index 2f99311,ed2c04e..4b3fb43
--- a/.travis.yml
+++ b/.travis.yml
@@@ -14,10 -31,10 +14,6 @@@
  
  #
  # Smoke all branches except for blocked* and wip/*
--#
--# Additionally master does not smoke with bleadperl
--# ( implemented in maint/travis-ci_scripts/10_before_install.bash )
--#
  branches:
    except:
      - /^wip\//
diff --cc lib/DBIx/Class.pm
index a87cf4a,ba237a2..1adbe64
--- a/lib/DBIx/Class.pm
+++ b/lib/DBIx/Class.pm
@@@ -291,7 -271,7 +291,7 @@@ accessible at the following locations
  =item * Travis-CI log: L<https://travis-ci.org/dbsrgits/dbix-class/builds>
  
  =for html
--&#x21AA; Stable branch CI status: <img src="https://secure.travis-ci.org/dbsrgits/dbix-class.png?branch=master"></img>
++&#x21AA; Bleeding edge dev CI status: <img src="https://secure.travis-ci.org/dbsrgits/dbix-class.png?branch=master"></img>
  
  =back
  
diff --cc lib/DBIx/Class/SQLMaker.pm
index 245847b,e863a0f..31e39a7
--- a/lib/DBIx/Class/SQLMaker.pm
+++ b/lib/DBIx/Class/SQLMaker.pm
@@@ -31,96 -29,6 +31,96 @@@ Currently the enhancements over L<SQL::
  
  =back
  
 +=head1 ROADMAP
 +
 +Some maintainer musings on the current state of SQL generation within DBIC as
 +of Oct 2015
 +
 +=head2 Folding of most (or all) of L<SQL::Abstract (SQLA)|SQL::Abstract> 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 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 B<very> distinct life on its own, and is used within an
 +order of magnitude more projects compared to DBIC, it is prudent to B<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 B<DBIC will no
 +longer depend on SQLA> at all.
 +
 +B<The L<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 C<SQL::Abstract> namespace.
 +
 +This work (if undertaken) will take into consideration the following
 +constraints:
 +
 +=over
 +
 +=item Main API compatibility
 +
 +The object returned by C<< $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 L<case|SQL::Abstract/case> or L<logic|SQL::Abstract/logic>
 +or even worse L<convert|SQL::Abstract/convert> will definitely remain
 +unsupported, the rest of the tests should pass (within reason).
 +
 +=item Ability to plug back an SQL::Abstract (or derivative)
 +
 +During the initial work on L<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 L<SQL::Abstract> from regressions in the future.
 +
 +=back
 +
 +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.
 +
 +=head2 Relationship to L<Data::Query (DQ)|Data::Query>
 +
 +When initial work on DQ was taking place, the tools in L<::Storage::DBIHacks
- |http://github.com/dbsrgits/dbix-class/blob/current/blead/lib/DBIx/Class/Storage/DBIHacks.pm>
++|http://github.com/dbsrgits/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 I<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 I<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.
 +
  =cut
  
  use base qw/