Fix set_column on non-native (+columns) selections (RT#86685)

Tighten even more inflate_result() invocations, for crazy overloads

Ensure collapse is respected regardless of selection type

Switch the attribute name/logic (passthrough on explicit presence only)

Upgrade the "too many args on customcond" warning from 1adbd3f to an exception

Add reference to RT for the fix from d0cefd99

Bring back resolve_condition deleted in 03f6d1f7

It doesn't cost anything, and the compat shim turned out to be good enough
to make this worthwhile. Also apparently CPAN is using it still FML:
http://grep.cpan.me/?q=->_*resolve_condition

This was an embarrassing close call - entirely redo custom set_from_related

I am flailing at this point - unacceptable. TL;DR: 03f6d1f7 is wrong, 1adbd3fc
is wrong, so is 5592d63 and most importantly 350e8d57 is unacceptably wrong.

The entire "I will inflate a bag of data into a synthetic object" was wrong
from the very beginning (03f6d1f7) but I was too busy keeping the tets passing
to realize what crack-mountain I was standing on.

The crux of the issue is: it didn't occur to me that forward-resolution
(related_resultset) *always* starts from an object by definition, while
reverse-resolution (set_from_related) takes either an object or a bag of
values or undef. Moreover: in the custom coderef the user does not care at
all about the type - all they want is to get their values. In light of this
self_result_object is actually a mistake - we should have simply provided
self_values from the start, but that ship has already sailed. On the other
hand the reverse-resolution bag is a new feature, and we can simply (and
correctly) settle on passing in a hashref of values: foreign_values

This fully avoids the "how do I get an object out of plain data" problem
and nicely settles all the outsanding (untested until now) problems.

I just wish I would have seen this a week earlier... sigh. At least not
shipping this live is a consolation...

Change version style/handling (doc coming up shortly)

Minor limit dialects doc fix

Added support for handling Class::DBI::Column in CDBICompat

Added handling for implicit inflate/deflate of CDBI has_a relationships

Add 3rd example of col info in ResultSource->add_column

Rather than just say "it's a hashref", provide a simple example of what that
hashref might look like.

The current_source_alias is prepended, not a literal "me."

Bundle trial SQLA for the trial of DBIC (reuse dq technique f4a8b21e)

Supersedes 609fa215, to be reverted before 0.082800

Correct test of ${^WARNING_BITS} - as haarg++ noted: runtime != compile time

Also bump Moo prereq for proper
 * presence of undefer_all
 * fixes of meory leaks in Sub::Quote/Sub::Defer

Document and add example of foreign_related_object

Change once more the signature of the custom cond coderef (augment a446d7f8)

Since there hasn't yet been a stable release with the new naming, and given
I've already mistyped the long-form twice, might as well rename things and
stay consistent.

Now that populate is rewritten: finalize the resolver fatal sanity checks

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

One more output for the resolver - used in next commit

Note that the column equivalency map is calculated for both types
of rels, which is crucial down the road

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 :(

Avoid ResultSourceProxy calls whenever possible

Along with efficiency gains this commit makes a very subtle but crucially
important change: From here now on when we operate on an instance, we are
guaranteed to query this instance's result source. The previous codepaths
would nearly randomly switch between the current rsrc instance and the one
registered with the corresponding result class.

This will allow for proper synthetic result instance construction further on

Rebase Oracle datetime inflation test on top of DBICTest::Schema::Event

The butchering of Track made sense in 2007, not so much today

The test seems to behave identically, hope I didn't fuck up anything...
https://travis-ci.org/dbsrgits/dbix-class/builds/30513847#L398

Replace many closure-based proxy methods with static qsubs

Not only does this buy a quantum of performance, but it greatly enhances
readability of these methods on deparse

Deliberately not converting the ManyToMany helper - this code needs a
thorough regut :(

Reformat add_relationship_accessor for future edit

No functional changes, read diff under -w

Standardize the Moo import block, move quote_sub/qsub into ::_Util

This way we will have less boilerplate in subsequent commits where we
will use quote_sub standalone

Add yet another test to make absolutely sure quote_sub won't leak any of the
strictures insanity

Replace B::perlstring with our own implmentation thereof

Haarg++ for pointing this out

Add internal assertion guard for some indirect calls (for now only create/new)

Modeled on the idea of a9da9b6a, this one blows up when a public proxy
is called insted of the equivalent public chan of methods

This particular set of changes to create() and new() is solely an
optimisation (unlike a subsequent commit to ::ResultSourceProxy)

Greatly improve diagnostic messages of _resolve_relationship_condition

Remove duplicate arg-check in create(), adjust exception text

Simplify no wantarray assert (a9da9b6a) - fish out args from caller

is_X_value functions introduced in 3705e3b28 migrated to SQLA with fixups

Better, consistent handling of -literal/-value in the cond collapser

(travis) Temporary hard-spec of the SQLA dep, lockstep release

Move the "special loading" check to DBICTest::Util

No functional changes

Skip the namespace tests on plain install

Protect users from future spurious changes in uncleaned imports

(travis) T::B 1.005 is superseded by 1.300 - remove handholding

Add one extra is_exception check (missed a spot during 841efcb3f)

In addition tweak the message so that carp_unique can in fact catch it
properly, and test that the proper amount of warnings is in fact emitted

Consolidate bits and pieces under ::_Util::refdesc

No functional changes

Remove double has_column check in new=>store_column

Standardize exception texts across ::Row

Another heavy refactor of the rel resolver prototype (sequel to 03f6d1f7)

Change the return value of _resolve_relationship_condition to a 3-value
hash, with a lot of the safety logic consolidated within that method. The
best way to gauge the significance of the changes is to look at the diff
of lib/DBIx/Class/Relationship/Base.pm

Also stop returning the "noncondition-columns" in the _resolve_condition
compa-shim. The information was only used by the code removed from
::Relationship::Base, and is rather new with no evidence of use within
CPAN/DarkPAN. It can be easily added back if necessary.

Move a CDBI escape to the CDBI class hierarchy

Refactor ::DBIHacks::_extract_fixed_condition_columns (sequel to 8d005ad9)

Instead of just returning an array of column names, switch to a hashref that
can double as an inferred-value bag. As a bonus deduplicates and folds-in
another codepath from ::ResultSet::_merge_with_rscond

In the process fixup _collapse_cond to be even more robust in some arrayref
corner-cases. Now it is guaranteed to return a hashref at all times

Switch UNRESOLVABLE_CONDITION to an _Util constant

Older perls get confused by this construct - rewrap

Revert optimistic and sloppy changes from 3705e3b2 - DBI does not always DTRT

In addition I rebroke the issue from RT#79576, ffs man pay attention

<ribasushi> general question - does DBI guarantee that objects with stringification overload will get their stringification called
<ribasushi> or is this up to the DBD (and thus will vary)
<mje> ribasushi, I had an issue in DBD::ODBC ages ago with this - looking for it now
<mje>  rt 78838 - bind_param does not correctly stringify blessed objects when connected to MS SQL Server, magic was not being applied in DBD::ODBC case
<mje> so I think the answer to your question is DBI does not but DBDs should if they are written correctly
<ribasushi> I wonder why DBI does not
<timbunce_> ribasushi: no explicit ‘guarantee’ but I think any place it doesn’t is probably a bug.
<ribasushi> timbunce_: given mje had to do magic in his DBD, I suspect DBI has a "hole" somewhere then no?
<ribasushi> basically I was looking into removing the explicit stringifications in DBIC, hence the question
<ribasushi> if there is consensus that DBI ought to do it all on its own, we could test for it, fix it up, and then I disable the checks when I detect a sufficiently advanced DBI.pm
<timbunce> yes, ribasushi: “… we could test for it, fix it up, and then I disable the checks when I detect a sufficiently advanced DBI.pm or something”
<timbunce> :)
<ribasushi> nod ;)

Initial (now passing) tests prompting the order_by analyzer revamp 302d35f8

Teach order_by stability analyzer about search_related

There is more stuff we can do here as noted in the FIXME added to the very
end of _extract_colinfo_of_stable_main_source_order_by_portion. But for the
time being this will do (also see the subsequent tests for extra insanity we
could and should add)

Tests come in the next commit

Pass the main rsrc in attrs, instead of trying to fish it out later

Clearer name of method/variables before refactoring

Switch DBIC::Storage::Statistics to Moo (for trial purposes)

This is a component which has some subclassing in the wild, use it as a
canary to highlight any remaining issues Moo might have within DBIC

Break out the test tracer into a standalone file

IFF debug goes to STDERR by default - silence possible wide-char warnings

Stop permanently enabling autoflush on the debug filehandle

Expand closed STDERR test, check actual exception

Better (and much more precise) explanation of Moose/Moo subclassing

Better example/documentation of custom resultset classes

Change tab space (4 => 2), no further changes

Move the Subclassing POD under Examples

namespace::autoclean is a really stupid idea - purge with fire

Forgotten reenable of syntax test to guard for 37af2968e

Add an explicit webchat link, change IRC to x_IRC

This should work around the issue of 'preferred company/startup' raised in
https://github.com/CPAN-API/metacpan-web/issues/1235#issuecomment-47610925

Improved docs for ResultSet columns attribute on how to retrieve related columns

More coherent +(columns/select/as) quoting notices and descriptions

Populate caches for related result sets even if they're empty

This avoids unnecessary database hits when accessing prefetched related
resultsets with no rows.

Add a self-explanatory *compile-time* $ENV{DBIC_SHUFFLE_UNORDERED_RESULTSETS}

The idea is to be able to catch tests that rely on a particular order of
the results of ->all. ->next is untouched as injecting extra \'RANDOM'
order clauses is too heavy-handed for a test environment (and besides, having
->all and ->next return stuff in differing order is just as good of a
monkey-wrench)

Minor optimization of codepath (no func changes)

Fix ::Ordered in combination with delete_all

See pod-changes for description of the solution. I cringe but... oh well

(travis) Announce what we set during POISON_ENV

Remove vestigial test envvar

More fallout of the _resolve_cond refactor 03f6d1f7

I had in the back of my mind "one can't just create random objects" but
figured it may work anyway - WROOOOOOOONG. Instead pass through the hash
as before, will need to rethink that part before settling on an API for
resolve_relationship_condition. FML

Fix test tripping on external warnings

Even more robust _resolve_condition shim - guess rel_name when needed

replace all remaining uses of self_rowobj with self_resultobj in pod, test schemas

Add (now passing) tests for set_from_related() via 'foreign_resultobj'

Add foreign_resultobj to the customrel signature

Tests in next commit

Pedantry - settle on rel_name vs relname, consistency throughout

Only outlier is relname_to_table_alias, which should have never existed
in the first place. Punting deprecation/etc cycle until future Oracle
work... sigh

Rename (with a silent compat shim) couple of badly named customcond args

foreign_relname makes absolutely no sense - it *is* a relationship after all,
of course it has a name. Now renamed to rel_name to be consistent with
the relationship condition resolver

self_rowobj uses the old rowobj nomenclature - switch to self_resultobj

Centralize custom rel args check, be more thorough

Adjust error messages - joinfrees can be returned from noncode rels

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...

Fix incorrect handling of custom relationship conditions containing literals

Revert heading change from 06752a03d, centralize the URL spec

There were several broken links referring to the old way of doing
things, and help/support sounds better anyway. Reverting with added
comments and whatnot

Fix grave resultset-level delete/update bug

In case of a read-modify cycle (usually due to multicolumn PK, without
multicolumn IN support) DBIC would end up with a null condition and nuke
the entire underlying table from orbit

I have no words towards my younger self...

Do not skip running from_storage filter when a NULL is returned

Use a nullable column for the ::FC test

This is just a retarget, no test was actually modified

Teach FC about literals

A number of equivalent-logic ::FC refactors

Stop invoking a comparison on the unfiltered values - delegate it properly
to set_column()

Reorganize IC column setters

Should again result in no functional changes

Rename some variables and reformat the FC/IC codepaths for clarity

Zero functional changes

Clarify FC/IC conflict exception

Call mro reinit in tests only on 5.8

Fix incorrect handling of stringifiable objects in cond collapser

Thinko introduced in the recent 8d005ad9

Consolidate handling of "is this a literal" and "is this a value"

In the process fix inability of IC to deal with \[], and simplify
the overal codepath bind value passing codepath

Aside from the bugfixes there should be no functional changes

Work inspired by a report and preliminary patch from dim0xff++

Use the correct $PROGRAM_NAME for the initial dbicadmin POD gneration

spelling fix

Retire DBIC/SqlMakerTest.pm now that SQLA::Test provides the same function

Switch most remaining debug-hooks to $dbictest_schema->is_executed_querycount()

Retire DBIC::DebugObj, replace with $dbictest_schema->is_executed_sql_bind()

This cuts down on a lot of the silliness with debugcb/debugobj, and makes
for more precise tests as a whole. Went through great pains to not disturb
any existing tests, fingercross this is indeed the case

Read under -w for sanity

Excise live test left over after ac0c082542

No access to a live test system currently, and likely the test is incorrect
anyway (no mention of significant parenthesis)