First step to add some sanity to _resolve_condition
authorPeter Rabbitson <ribasushi@cpan.org>
Wed, 11 Jun 2014 10:05:13 +0000 (12:05 +0200)
committerPeter Rabbitson <ribasushi@cpan.org>
Wed, 11 Jun 2014 15:28:34 +0000 (17:28 +0200)
commit03f6d1f7b65051799423237e9401689c1b43ad95
tree54c9ee1830b67e0a76776fe47bfef0ad0b0e75fc
parentf8193780f1e03bc6f1316204a03bf604faf9267b
First step to add some sanity to _resolve_condition

The original problem starts here:
 <mst> oh, yeah, I just used to check ref and randomly swap things
 <mst> it worked for enough years :)
 <ribasushi> I will be forwarding you my psychiatrist bill

READ DIFF AT YOUR OWN RISK

Over the years _resolve_condition has accumulated 3 (or 4, or 5, depends
how you look at it) distinct call-modes. None having anything to do with
another. Also it is a hot method, holding crucial functionality, which
of course means that currently at least 3 projects on CPAN are using it,
despite the private attribute. Which in turn means couple more orders of
magnitude of users on the DarkPAN. Thus just killing this method
outright *without a replacement* is not an option.

A from-scratch replacement in the face of only one person currently
*barely* understanding this codepath is a scary proposition.

Instead create an elaborate (and scarily complete) shim to proxy to a
new method holding all the logic (with the idea of making it an official
API in the coming commits).

There are no changes to any other codepaths, as this is how we ensure that
the shim is sane, and works. Next step is to erradicate all cases of the old
call in the current codebase (while leaving the sub/shim intact)/

Now let's see if we can fix CampusExplorer's bugs first...
Changes
lib/DBIx/Class/Relationship/Base.pm
lib/DBIx/Class/ResultSource.pm