Resolve $rsrc instance duality on metadata traversal
authorPeter Rabbitson <ribasushi@cpan.org>
Mon, 25 Apr 2016 09:53:54 +0000 (11:53 +0200)
committerPeter Rabbitson <ribasushi@cpan.org>
Mon, 25 Jul 2016 12:40:54 +0000 (14:40 +0200)
commitf064a2abb15858bb39a141ad50391d4191988d2c
treed299cf2a12ec163d35e4c793e197252fee3880e7
parent0ff3368690783358903b3689a1a96ef21271f825
Resolve $rsrc instance duality on metadata traversal

Make result_source a straight wrapper around result_source_instance. This
should fix all the fallout introduced in 0.082800 (4006691d), which sadly
went undetected all the way until ~7 months after its release. Ultimately
this is my fault, as I had an early warning, and even later made a conjecture
which spot exactly may blow up in my face (read towards end of 350e8d57)

Exploit the fact that result_source_instance until very recently was a toss-up
between a CAG 'inherited' and a Class::Data::Inheritable (removed in 5e0eea35)
with CAG not really involved in result-instance level calls, and the latter
making it downright impractical due to the closure-based approach. Combined
with the fact that result_source was a 'simple'-type accessor pointing at
the '_result_source' hash-slot allows us (at least seemingly) to switch to a
setup where result_source is nothing but a wrapper around a CAG inherited
accessor result_source_instance which point to the named slot '_result_source'

The changeset is deceptively small, and is kept this way for easier auditing.
See next commit for the armada of additional testing to verify the entire
stack is in fact still solid.
Changes
lib/DBIx/Class/ResultSourceProxy/Table.pm
lib/DBIx/Class/Row.pm
lib/DBIx/Class/Schema.pm
t/resultsource/add_column_on_instance.t [new file with mode: 0644]
t/resultsource/instance_equivalence.t [new file with mode: 0644]