Fix both a dubious test and a regression in populate args immutability

The rewrite in d0cefd99 optimized populate enough that the same data structure
would now make it all the way to the stringifier in ::Storage. This was not
caught due to a deficient test.

Read diff under -w for maximum sense

Cosmetic rearranging/renaming of some parts of the populate codepath

Zero functional changes

strip schema name from ADD CONSTRAINT / CREATE INDEX

 * Pg tablenames may have a schema prefix.  This leads to invalid ADD
   CONSTRAINT / CREATE INDEX statments being generated by ->deploy(),
   since constraint and index names may not have a period in them. This
   patch strips the schema part from the table name when constructing
   unique index and constraint names.  The fix was taken from
   ribasushi's email to the mailing list:

   http://lists.scsys.co.uk/pipermail/dbix-class/2013-February/011141.html

"Fix" symptoms described in ba7892a8c4 (I still do not entirely get it)

Extra fail reports are:
http://www.cpantesters.org/cpan/report/f74def2b-6bfb-1014-b341-c67b58fe2ee5
http://www.cpantesters.org/cpan/report/3123ab19-6bf8-1014-b488-656aa945bbef

Ensure proper behavior when quoting is *disabled* (wraps up 08ac7648)

The extra reltype flag is breaking some suites - make the full change

Might as well get this over with, still consistent with Swindon

Remove unused leftover from c19ca6e80 - there was much flailing :(

Kill rel-exists sanity checks for 28, reinstate them later

Something that simple allows RapidApp to pass its tests without modifications
in other words - worth the pain

The fix in f9b5239ac was both shortsighted and insufficient

Move the quote_names => quote_identifiers inferrence into ::Storage::DBI
proper, and ensure tests cover it this time

Also bump SQLT dep, as the previous version throws on diffing DBICTest::Schema
under SQLite

Check relationship declarations more consistently

Revert improved test added in b6b8f72f, replace with original from dabe173a

The new test contains a case which it *seems* to me needs to be an exception.
Since we are already pretty late with 28, I am just reverting the test alone
(while keeping the changes). This way I am not backing myself into a corner
with a published test in 29.

More diag from t/53lean_startup.t when under smoker env

Trying to pinpoint cause for the following two:
http://www.cpantesters.org/cpan/report/c13d6ffc-6bf4-1014-8850-81d5948d76d3
http://www.cpantesters.org/cpan/report/51d7cbe3-6bf5-1014-88de-68e8687ecb02

A little cleanup of ->id callsites (incomplete)

This is just to stave off an unlikely but possible 'id' colname masking a
multicol PK

The real workaround is to do something akin to Moose's ->meta, but that's
another battle.

Properly throw on FC with find (it can never work anyway)

This is the proper solution for RT#95054

Deprecate _build_unique_cond, move its guts to ::ResultSource where it belongs

The merger failing is no longer a possibility after 8e40a627

Remove the useless try{} block

Shuffle logic in find() a bit, no functional changes

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