Entirely and utterly rewrite populate(), fixing the variable hash issue
authorPeter Rabbitson <ribasushi@cpan.org>
Tue, 10 Dec 2013 08:37:32 +0000 (09:37 +0100)
committerPeter Rabbitson <ribasushi@cpan.org>
Wed, 23 Jul 2014 21:38:07 +0000 (23:38 +0200)
commitd0cefd99a98e7fb2304fe6a5182d321fe7c551fc
tree8af0f336f7f871a71a43273492cd1c5c892206f1
parentc19ca6e801814466346f4b0f3793303561438312
Entirely and utterly rewrite populate(), fixing the variable hash issue

Yes, it took ~3 years to properly fix it. The changeset size alone should make
it pretty clear why this happened, but this is not the entire story.

At first the bug was deemed fixed back in a9bac98f. Due to miscommunication
and lack of tests this issue did not come up again until last winter (the devs
thought they nailed it, the users thought it's a wontfix).

Then when the actual tests got written it became clear that... words fail me.
In short - some folks had the bright idea that a fast-path insert got to be
able to understand *MULTI-CREATE* semantics. There was a great deal of tests
that did all the wrong things from a conceptual point of view but they were
passing tests nonetheless. So the thing got tabled again...

In the meantime a recent flurry of improvements to the relcond resolver
took place, mainly centered around fixing the custom relconds call modes.
A side effect was uncovering that populate() is invoking relationship cond
resolution in an... insane for the lack of a better word way. Some shims
were put in place and the only remaining bit were warnings, however with the
improvements available it in fact possible to cleanly implement
"subquery-based multicreate".

So instead of punting - the entire codeflow of populate was reworked with the
new toys in mind. The data mangler _normalize_populate_args is gone for good
(no more mindless copy of passed in data). The amount of fallbacks to create()
is reduced and each instance now properly warns of the problem. All in all
this is another one of "if something changed - I fucked up" changes.

As an added benefit - we now have a foothold into validating subquery-based
multicreate implementations - soon (one would hope) the code will migrate
to wider use within ::ResultSet.

A notable part of this commit is the *undocumented* implementing part of the
Swindon consensus - the is_depends_on flag is now added to all belongs_to
relationship attrs. The actual implementation of the rest is subject to
another battle.

Now on to 0.082800
Changes
lib/DBIx/Class/Relationship/BelongsTo.pm
lib/DBIx/Class/ResultSet.pm
t/100populate.t
t/101populate_rs.t
t/multi_create/standard.t