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)

Consolidate pg/mysql and standalone SQLite savepoint tests to run on all 3

A larger consolidation will take place later with T::WV, but all in due time

Fix multiple savepointing transactions on DBD::SQLite

Problem was missed during review of 86a51471ce (how the fuck did I let this
abomination through anyway), and not encountered due to insufficient testing.
The naive statement parser in DBD::SQLite when running against older libsqlite
mistakenly treats ROLLBACK TRANSACTION TO... as an actual TXN rollback, and
as a result desyncs the internal AutoCommit flag state [1]
Fix by simply using the shorter (still valid) syntax [2], and by removing the
sloppy workaround hiding the actual problem.

[1] https://github.com/DBD-SQLite/DBD-SQLite/blob/1.42/dbdimp.c#L824:L852
[2] http://www.sqlite.org/lang_savepoint.html

Fix erroneous todoification in sqlite test

Less warning noise from sqlite test

Move the DSN-lock machinery from 8d6b1478d into DBICTest::BaseSchema

This is just a c/p job, expecting zero functional changes

The t/admin/02ddl.t are cosmetic changes fixing a nested &cref leak never
before encountered on <= 5.8.7

Consolidate lib-wide frameskip, adjust the ::RunMode loading order

Reaching for IO::File here makes no sense

This test was essentially c/p-ed in 2cc3a7be3, consolidate

The overriding difference is the new-connection == new-storage == new-sqla
Add an explicit codepath to test that, but overall there is plenty of
other places that verify this behavior to death

Examine under -w -C -M to make sense out of the consolidation (minimal
changes were attempted)

Improve complex order+prefetch exception message

Updated discard_changes docs regarding { force_pool => 'master' }

The initial (now passing) test for RT#93244 (fixed in 8d005ad9)

Massively refactor and sanify condition collapsing

Wow... what a ride. This commit adds a faithful reimplementation of the
SQLA descend algorithm, but instead of SQL produces a reduced HASH that
nevertheless corresponds to the original query 1:1 (or so I *really* hope)

This is another one of these "I can try it with DQ but I don't even have
tests" stories, so once again opted to implement things the "dumb" way.

The benefits are quite substantial:
- Better deduplication of WHERE condition
- Consolidated functions - the vaguely similar logic in the current version
  of _collapse_cond replaces almost the entirety of:
    ::DBIHacks::_extract_fixed_condition_columns
    ::ResultSet::_collapse_cond
    ::ResultSet::_stack_cond
- Extra fixes for create/populate inheritance corner cases
- More predictable SQL condition generation order (which incidentally may
  prove problematic down the road with broken tests, but oh well, we'll
  burn when we get there)
- Ton of extra tests and corner cases

We even managed to fulfill a longstanding TODO, even though it is a *lucky*
side-effect and not a real fix. Making a note to address this later... sigh.

This work started from d8b7d9f58..337f3ee80, which while taking the right
direction had too many loose ends. ilmari++

Remove dead code missed by cleanup b72339859

Add test ensuring we do not lose binds on esoteric RSC+distinct

Test inspired by auditing cc2b92553 (a precursor of ad1d374e60)

Refactor _recurse_fields to return the bind values

Only ->select actually wants it in $self->{select_bind}, the others
either don't care or want them somewhere else.

Fix multi-value literal populate not working with simplified bind spec

This arcane use-case got missed when 1b5ddf23 was integrated

Fix bogus reference to related class (introduced way back in 97c96475)

Remove forgotten part of a48693f4 (incompletely reverted by e327f126)

$pedantry =~ s/columns/column/

Properly detect and test mysql v3 default JOIN behavior

While investigating how to rewrite the rather useless 39712b481, it became
clear that not only can the test be performed offline, but that there is
already a pseudo-test due to sqlite's version of 3.x.y being mistaken for
MySQL 3

Properly fix the test to check behavior on both versions 3 and 4, and in the
process fix a potential bug of a stale sqlmaker when a reconnect cycle takes
place against a *different* physical rdbms (which btw makes me realize another
problem with trying to do mixed-environment replication... sigh)

Clarify that sql_maker is just a getter at this point

Minimal optimization of the new+prefetch codepath (no func. changes)

Fix missing true return lost during e5a62c46f

This never resulted in a serious problem because it was papered over by a
bug in Class::C3::Componentised. Addressing it at the source requires a bit
extra coding, hence no new CC3C release yet.

Add explicit AS keyword to RowNum (Oracle) limit dialect

This should have no effect on the actual query, only done to bring in line
with the generalized DQ engine

Add extra fetch_first test for right-side-only order

Add progress meter to travis builds