Re-fix relcond resolver: revert 5592d633 (in turn partial revert of 03f6d1f7)
authorPeter Rabbitson <ribasushi@cpan.org>
Mon, 21 Jul 2014 16:45:06 +0000 (18:45 +0200)
committerPeter Rabbitson <ribasushi@cpan.org>
Tue, 22 Jul 2014 01:50:07 +0000 (03:50 +0200)
commit350e8d57bf21e4006e2a5e5c26648cb5ca4903ea
treee3ebbd8cdb86a10803381ac091573861e1858133
parent4006691d207a6c257012c4b9a07d674b211349b0
Re-fix relcond resolver: revert 5592d633 (in turn partial revert of 03f6d1f7)

I had the right hunch during 03f6d1f7 but could not substantiate it: the
issue is that the custom coderef expects objects or nothing. Yet here and
there internals pass around bare hashes of data (or sometimes even undef).

Asking users to complicate their coderefs further is just not an option -
it is mindbending enough as it is. So the only way to go forward is indeed
to create "synthetic result objects" and pass them down the stack. This time
however there is a twist - after the overhaul in 4006691d we now *can*
indeed construct such objects on top of the bare DBIx::Class::Core - in
other words mission fucking accomplished.

This commit *may* need to be reverted in case it turns out that 4006691d is
a no-go (check the test change to t/inflate/datetime_oracle.t in 12b348d9
for an example of what was taken for granted wrt direct $class-> calls)
If this is the case - not all is lost. We should be able to use a hidden
class with an actual source instance that we would ammend on the fly... But
let's hope we will never get to this bridge :(
lib/DBIx/Class/ResultSource.pm