Permalink
Switch branches/tags
Commits on Dec 8, 2016
  1. Introduce GOVERNANCE document and empty RESOLUTIONS file.

    shadowcat-mst committed Dec 8, 2016
    To understand the process that lead to this commit, you'll probably need
    to read all of:
    
    http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/date.html
    http://lists.scsys.co.uk/pipermail/dbix-class/2016-November/date.html
    http://lists.scsys.co.uk/pipermail/dbix-class/2016-December/date.html
    
    Any attempt on my part to summarise it would likely seem insufficiently
    accurate to me and biased to at least some readers, so I'm not even going
    to pretend to try. If you're trying to achieve a tl;dr, I suggest checking
    the December archive in the hopes that somebody posts a summary there some
    time after I push this commit.
Commits on Sep 30, 2016
  1. Merge the last bits of indirect callchain optimization

    ribasushi committed Sep 30, 2016
    This set of commits (again - merge for easier bisect) is exclusively dealing
    with various wantarray()-aware methods, most notably ::ResultSet::search()
    
    Wide smoke of downstream adds only 3 extra dists to the list of "passes tests
    but warns about indirect-sugar overrides" as shown in 12e7015. In the cases
    below all overrides are that of search() - a rather legitimate problem to be
    warning about
    
      Catalyst::Controller::DBIC::API
      DBIx::Class::Helpers
      DBIx::Class::ResultSet::AccessorsEverywhere
    
    No other known breakage as of this commit
  2. Simplify internal implementation of as_subselect_rs

    ribasushi committed Sep 27, 2016
    Zero functional changes
  3. Audit and minimize use of last major indirect method: search()

    ribasushi committed Sep 22, 2016
    I am not entirely sure how I missed it during 1b822bd, but oh well. This
    should be the last highly volatile part ( as far as downstream is concerned ).
    
    As previously - zero functional changes apart from no longer calling search()
    at several spots (the SanityChecker ensures none of this results in silent
    breakage)
    
    All spots that *do* require wantarray()-specific behavior remained explicit
    wrappers for search(), instead of doing the wantarray() check themselves: this
    is a deliberate choice to allow DBIC::Helpers::ResultSet::IgnoreWantarray or
    similar libraries to continue operating by simply hooking the search() method
  4. Retire the ASSERT_NO_INTERNAL_WANTARRAY macro

    ribasushi committed Sep 30, 2016
    It was a good idea for its time, and helped clean up the codebase a lot, but
    ASSERT_NO_INTERNAL_INDIRECT_CALLS currently covers all its functionality and
    does so in a way less fragile (stateless) manner
    
    Mark several more methods as indirect_sugar, leaving only one forgotten spot
    for last (see next commit)
    
    No functional changes
    Read under -w
  5. Audit and annotate all context-sensitive spots in ::Ordered

    ribasushi committed Sep 30, 2016
    Ensure an upcoming commit will not disturb the established (silly but still)
    API of the resultset-returning methods. Review, annotate and tighten up spots
    that have to do with wantarray-like behavior
    
    Not using the ASSERT_NO_INTERNAL_WANTARRAY macro as it is about to be retired
    in a subsequent commit. Instead adjust the INDIRECT guard to correctly interpret
    eval frames
    
    Zero functional changes
  6. Restore the context sensitive m2m helper calling of ->search

    ribasushi committed Sep 28, 2016
    Subtly modified in 11e469d, this prevents things like the ::IgnoreWantarray
    helper from taking effect in this case.
    
    An audit of all other wantarray() invoking sites did not reveal other issues
  7. Mark forgotten ::Row::id() method as indirect_sugar

    ribasushi committed Sep 29, 2016
    Discouraged legacy sugar, which does not even work properly with multicolumn
    keys in scalar context. Mark properly as INDIRECT to ensure DBIC does not rely
    on it anywhere
    
    Also adjust the SanityChecker to not complain about shadowing of sugar methods
    with generated ones (i.e. column accessors) - while unfortunate, this kind of
    thing happens quite often (especially with such a generic name as 'id') and
    warning about it would make no sense (left alone that methods which are
    ..._generated_from_resultsource_metadata generally do not invoke next::method
    anyway)
  8. Tighten up code in ResultSetColumns, add INDIRECT annotations

    ribasushi committed Sep 30, 2016
    No functional changes (nothing else in lib/ and t/ had to change)
  9. Fix func_rs() and as_subselect_rs() to start behaving as advertised

    ribasushi committed Sep 27, 2016
    No idea how it never got noticed, but both have been broken since the very
    first commits that introduced the methods ( 4fa7bc2 / e4bb672 ). While
    changing them 7 years later is a rather serious modification of behavior,
    the old way never worked without users having to force-scalar each call site.
    
    If someone has been relying on e.g. [ func_rs(...) ] to return actual result
    objects instead of the resultset instance - things will blow up rather quickly
    and loudly (aside from the carp()-ed warning encouraging users to switch to
    scalar ctx explicitly)
    
    [ func( ... ) ] of course continues to behave like before (directly returning
    raw values off the cursor... sigh)
  10. Tighten up select list processing in ::SQLMaker

    ribasushi committed Sep 30, 2016
    Optimize some of the codepaths (do not recurse in spots where it makes no
    practical difference).
    
    Deprecate searches with no explicit select-list ( can't remove it outright due
    to downstream breakage :/ )
Commits on Sep 28, 2016
  1. Fix building on perls with no . in @INC

    ilmari committed Sep 28, 2016
    Perl 5.26 will be able to be built with no . in @INC,
    and Debian are already building their 5.24 without it.
    
    To cope with this, do -It/lib -MFoo instead of -Mt::lib::Foo.
Commits on Sep 27, 2016
  1. (travis) Work around RT#117959

    ribasushi committed Sep 26, 2016
    A real fix for this ticket is pending, but had to be bumped a bit
  2. Remove the only use of the CAG 'inherited_ro_instance' group

    ribasushi committed Sep 27, 2016
    Introduced for reasons unknown back in 93405cf, it is currently nothing but
    baggage - especially given the lack of name synchronization as described in
    one of the comments in 28ef946
    
    grep.cpan.me indicates no use in the wild, so just kill it with fire
  3. Merge the relationship resolution rework

    ribasushi committed Sep 27, 2016
    Done as a merge to aid bisecting IFF it ever becomes necessary
    
    Wide testing indicates zero need for downstream changes (aside from several
    warnings)
  4. Promote resolve_relationship_condition to a 1st-class API method

    ribasushi committed Jul 30, 2016
    The encapsulated logic is just too complex to try to replicate externally,
    especially now that everything within DBIC itself uses this method underneath.
    
    Patches to the only widely known user (::Resultset::RecursiveUpdate) will
    follow shortly
  5. Protect several resolve_relationship_condition() callsites

    ribasushi committed Sep 1, 2016
    Some external use of DBIx::Class::ParameterizedJoinHack revealed a couple
    sites where the relationship resolution may unexpectedly, yet non-fatally
    fail. This protects all the reasonable places (partially reverting b47fb9c),
    downgrading the exceptions to once-per-callsite warnings.
    
    I did not have time to dig to find the underlying problem, there may very well
    be a real bug lurking around :/
    
    For reproduction of the (now) warnings: see https://github.com/ctrlo/lenio
  6. Switch infer_values_based_on to require_join_free_values in cond reso…

    ribasushi committed Sep 24, 2016
    …lver
    
    This further simplifies the cognitive surface of the condition resolver API
    just like 786c1cd and a3ae79e. During the sprint to add at least *some*
    sanity to the codepath infer_values_based_on was introduced as a stopgap to
    allow 83a6b24 to somehow proceed forward. Since then the amount of spots
    where this logic is necessary steadily went down, bringing us to the current
    place: there is just a single spot in the entire codebase that passes a
    non-empty inferrence structure.
    
    Given the entire codepath is rather baroque, the entire idea of inferrence is
    pushed to new_related instead, leaving the API of the resolver itself even
    simpler.
    
    There are no known issues as a result, verified by re-running the entire test
    plan for downstreams as described in 12e7015.
  7. Switch reverse_relationship_info() to the relcond resolver

    ribasushi committed Aug 11, 2016
    Prompted by a PR from @mzealey, a code audit showed the entire implementation
    to be severely lacking. Switched to proper relationship resolution, with the
    added benefit of support for custom conds whenever possible.
    
    As of this commit every single relationship introspection now goes through a
    central point: _resolve_relationship_condition(). No more random ... eq 'HASH'
    checks all over the place.
    
    There should be zero functional changes as a result (aside from better custom
    cond introspection)
  8. Add an extra RV to the relationship resolver

    ribasushi committed Aug 10, 2016
    A certain spot in the codebase check whether a relationship is "simple".
    This additional flag allows to consider coderef conditions as well, instead
    of simply punting with "not a HASH? - no can do"
    
    See next commit for the actual switchover
    
    While at it fix a subtle bug introduced in b5ce674 - originally the helper
    is_literal_value recognized -ident as a valid literal. Later on during the
    migration into SQLA this logic was lost (I do not exactly recall the details),
    yet the DBIC side was never adjusted. All callsites were audited to make sure
    nothing else was missed.
  9. Standardize indication of lack of join_free_condition after resolution

    ribasushi committed Sep 18, 2016
    There should be zero functional changes as a result
  10. Some cleanup of the resolve_relationship_condition callsites

    ribasushi committed Aug 11, 2016
    Zero functional changes
    Read under -w
Commits on Sep 26, 2016
  1. Stop accepting foreign_values => undef/rowobj in the resolver

    ribasushi committed Aug 10, 2016
    There are just a few spots that need this, things are complex enough as it is
    
    Introduces a subtle change in behavior - now results of $foreign->get_columns
    are scrutinized just as a plain hashref, and as a result the sanity checks are
    somewhat relaxed.
    
    There should not be any fallout due to this - tested on a wide range of
    downstreams
    
    Adjust some tested-for exceptions added in 7e5a0e7 as a result of the above
    
    Read under -w
  2. Explicitly normalize results of relationship resolution

    ribasushi committed Aug 10, 2016
    Done as a separate commit to aid bisecting (in case it turns out problematic)
  3. Remove last internal use of the legacy _resolve_condition (find)

    ribasushi committed Jul 7, 2015
    Also fixes the overly coarse 'is it a HASH' check added in 49ca473/096f4212
  4. Tighten up value inferrence in relationship resolution

    ribasushi committed Aug 10, 2016
    Read under -w
  5. Extract couple more stateless functions from DBIHacks (like 497d045)

    ribasushi committed Aug 20, 2016
    Zero functional changes
Commits on Sep 19, 2016
  1. Fix unpredictable use of reverse_relationship_info() in the SQLT parser

    ribasushi committed Aug 27, 2016
    When reverse_relationship_info got introduced in de60a93, it was inexplicably
    mis-applied at the very spot it was needed in the first place. A result class
    pair can (and sometimes do) have more than one relationship between them,
    possibly with differing cascade_* settings. Grabbing the first set of values
    from the multi-member hash is inconsistent at best.
    
    Fix so that if at least one "hard-dependency" is encountered we go ahead with
    marking the reverse part as a CASCADE
  2. With time couple DBIHacks methods became single-callsite only

    ribasushi committed Aug 21, 2016
    Remove _inner_join_to_node and _resolve_ident_sources from the callchain
    entirely
  3. Centralize specification of expected Result class base in the codebase

    ribasushi committed Sep 19, 2016
    Some parts of the stack need to be able to disambiguate Result instances from
    other objects. In odrder to avoid tight coupling introduce a single override
    point $DBIx::Class::ResultSource::__expected_result_class_isa for esoteric
    use cases
    
    No functional changes
Commits on Sep 15, 2016
Commits on Sep 13, 2016
  1. (travis) Remove execution bits from the travis scripts

    ribasushi committed Sep 13, 2016
    No functional changes