Revert sloppy workaround in dabde0bc5, addressed by prev. commit

Tighten up the Firebird setup, add an explicit travis-brewed 5.10 smoke and
add extra randomness to the testing order in t/750firebird.t

Tested to bits with:

--- a/maint/travis-ci_scripts/40_script.bash
+++ b/maint/travis-ci_scripts/40_script.bash
@@ -28,15 +28,17 @@ if [[ "$CLEANTEST" = "true" ]] ; then
   run_or_err "Prepare blib" "make pure_all"
   run_harness_tests
 else
-  PROVECMD="prove -lrswj$VCPU_USE xt t"
+  PROVECMD="prove -lrswj$VCPU_USE t/750firebird.t"

   # FIXME - temporary, until Package::Stash is fixed
   if perl -M5.010 -e 1 &>/dev/null ; then
     PROVECMD="$PROVECMD -T"
   fi

+  for f in $(seq 200) ; do
     echo_err "$(tstamp) running tests with \`$PROVECMD\`"
     $PROVECMD 2> >(tee "$TEST_STDERR_LOG")
+  done
 fi
 TEST_T1=$SECONDS

Results at: https://travis-ci.org/ribasushi/dbix-class/builds/100894293

The complete fix for intermittent t/750firebird.t failures (RT#110979)

It makes no sense to throw values away in case the finish() failed - they are
good regardless. Not sure what I was thinking at the time :(

See also next commit

(deplist) Make it clear which non-existent yet known directories are in @INC

Also add explicit xt/ entries (not that I've seen this in the wild)

(travis) Make sure we really test everything when using cpanm (devrels)

This is to work around https://github.com/miyagawa/cpanminus/issues/462

Note: even if cpanm itself gets fixed, it will take forever for changes to
trickle down to various travis builds (currently 4 different configurations)

(travis) Work around RT#110882

(travis) Adjust test infrastructure for recent extensive TravisCI changes

I mean who does that?!?!
https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments

This is an initial pass to get things moving again, one more overhaul needs to
take place based on 7f6d73eb. For now just make sure we run under both sudo
and non-sudo, and be explicit which platform are we running on.

Read diff under -w

(travis) Fix version check on non-module-named dists (lapse from a223f7584)

(travis) Work around RT#107392

Fix POD typo

Fix typo

Move the rows/offset sanity checks from DBI to _resolved_attrs

Doing this much earlier should tie all loose ends wrt rows => 0 (sigh...)

Replace \D with [^0-9] in sensitive spots

(travis) Do not run the git authorship check within a github PR

Before running the CI test github "helpfully" generates a merge-commit,
which uses the email as listed in the github profile, NOT using the
email/name as seen on the merged commit itself. This can cause the entire
thing to fail for no apparent reason

Since any PR is scrutinized and tested to bits after the fact - skipping
the test is safe

Read under -w

Really make sure xt/ tests run on non-plain installs (fix c26b30de)

FACEDESK: Module::Install::Makefile::tests_recursive() takes a single arg and
throws the rest away... I mean what the flying...

Also remove some of the "is this plain user" checks from within xt/

Read under -w

Adjust view-dependency tests to work on newer libsqlite

The test and mechanism behind it is largely useless in these cases, but old
sqlite installations will lurk around for ever, so keep the check while moving
it to xt/

Fix spurious ROLLBACK statements when a TxnScopeGuard fails a deferred commit

This is a *temporary workaround*, and I am really unhappy about it... it just
feels wrong. See the comment in lib/DBIx/Class/Storage/TxnScopeGuard.pm

Fix oversight in 096ab902 breaking { -value => $array } insertion

This was never tested for, but also never shipped

Stop requiring explicit bindtype specification for non-scalar references

As ilmari correctly pointed out this is not necessary, I am not sure why I
didn't catch this on review...

<ilmari> ribasushi: why does DBIC think every DBD needs speical attrs to bind non-scalar values?
<ilmari> DBD::Pg handles binding arrayrefs autmoatically
<ribasushi> ilmari: at the time this was written DBD::Pg *did not* auto-infer bindtype for arrays, that's a relatively new thing
<ribasushi> ilmari: hmmm... this does not seem to be the case, will dig deeper...

Fix failures and protect the suite from spurious VERSION-related warnings

A new SQL::Translator devrel missed a s/_// line and made several tests fail

Fix t/752sqlite.t and t/icdt/offline_pg.t, and also add an obnoxious CI mode
to ensure we will not fall prey to this again

Fix bizarre segfault on older perls, not seen on CI ( augments d63c9e64 )

Fix test failure on 5.8.x with DBIC_TRACE=1 (introduced by 68b8ba54)

The CI run did not smokje this particular combination
TLDR: like ... qr/.../m does not work on 5.8.x due to P5#3038

Skip spurious compiler-related error with old DBD::SQLite and new gcc

FINALLY find and fix the elusive parallel test deadlock

For more details see https://rt.cpan.org/Ticket/Display.html?id=108390

Fix fail with DBICTEST_DEBUG_CONCURRENCY_LOCKS set (thinko in 69016f65)

Stop using bare $] throughout - protects the codebase from floating point hell

Issues similar, but likely not limited to, P5#72210 ( see prev commit)

(travis) One more addition to the smoke-devrel family: 5.8.8 with long-doubles

This one to catch fallout of https://rt.perl.org/Ticket/Display.html?id=72210

(travis) Now that File:Path is fixed, test the distbuild deps under devrel

This is not strictly necessary for anything I do, just add even more smoke
coverage to some pieces of the ecosystem (at the expense of extra 5 minutes,
but given it's in the "fail-ok" blocks - meh)

Add comprehensive concurrent-test-locking logging to aid future debugging

(travis) Minimize MySQL config further - even less chance of OOMs

Although in reality it is the preceeding commits that make the real difference

(travis) Stop using the ramdisk for MySQL/Pg data

Given the very low amount of RAM, the travis setup DOES NOT HELP. Instead of
fishing out the changed configs, just symlink the dirs back where they belong

(travis) When running under CI make t/storage/quote_names.t respect locking

Without this too many connections are fired at the MySQL and tasty OOMs occur

Reduce amount of initial connects during non-SQLite test-RDBMS lock-grabs

I am not sure why I wrote things this way back in 8d6b1478d, perhaps I didn't
properly think through that sqlt_type will be correctly determined no matter
what. As a result any MySQL test would connect at least once, and under the
right circumstances consume enough per-connection-thread memory to get a
low-RAM system (like TravisCI) to start OOM-killing things indiscriminately.

Switch several caller() invocations to explicit CORE::caller()

This not only fixes an obscure test failure due to an older Sub::Uplevel
(it would be too obnoxious to bump the dep just for the test case), but also
makes the entire codebase more robust in light of possible rogue/incomplete
caller() overrides

This was not a simple s/// job - each change was manually evaluated before
carrying out

Also while at it - fix the utterly annoying *UNKNOWN* eception site-marker:
it does not add any information and only confuses things. The heuristics in
Carp::Skip is supposed to be much much clearer, need to finish its tests...

Clarify comments/documentation regarding DBIC/SQLA/DQ relationship

This discussion comes up several times per year, just put it to bed for good

Even more aggressive streamline of SQL scanning in _resolve_aliastypes

No longer try to match individual pieces at all, simply treat every single
fragment as a single string. While rather barbaric, we are doing it anyway
in order to catch fragments, thus it makes no sense to keep the "proper"
codepath at all.

This concludes the shenanigans in this function

Save one _resolve_aliastypes in the case of a subqueried prefetch

Instead reuse a previously calculated one, since the code flow allows it

There *seem* to be no functional changes, but one never knows...

Instead of assembling many small regexes scan all the SQL in one pass

Speeds up the analyzer massively, now it's mostly SQLA itself holding things
back... sigh

A little more golfing - this time ::DBIHacks::_resolve_column_info

More surprising stuff showing up on the profiles...

Scanning strings piecemeal makes no sense - join them up

Read under -w

Another rewrap in ::DBIHacks::_resolve_aliastypes_from_select_args

No functional changes at all, just more efficient loops
Read under -w

Simplify DBIHacks order_by scan generator

There is no need to call out all the way to _extract_order_criteria -
we can do the necessary mangling ourselves

Normalize _parse_rs_attrs - no functional changes

The weird scan-for-binds-before-scan was obviated by a9e985b7

Tighten up code while at it, no functional changes intended

Simplify debugfh rebuilding after clearing

Fix invalid variable names in ResultSource::View examples

(travis) Add a dev-rel non-clean test (with distbuilding) on really old perl

The *really* old version is needed to make sure we end up upgrading as much
stuff as possible, thus hopefully trapping more dev-rel problems before they
end up on CPAN

( absence of this entry caused EUMM@7.06 to slip by unnoticed )

(travis) Revert pin of Sub::Identify (57947c1e)

(travis) Enhance checks (and diag) whether a core module did in fact upgrade

Trap exact condition of reported, yet undiagnosed IDENTITY_SELECT

Something is popagating the _autoinc_supplied_for_op flag where it shouldn't

Fix ::Sybase::ASE incorrect attempt to retrieve an autoinc on blob inserts

This is a temporary fixup, will be better taken care of with the lobwriter
  --ribasushi

Greatly simplify the ::Sybase::ASE::insert() override

The _insert sub-method actually isn't used by anything else, and as such is
not needed. The behavior has been verified to be identical by comparing
DBIC_TRACE=1=logfile runs before and after the changes.

Still - there may be dragons, if bisecting pay close attention to this fella

First pass on Sybase::ASE - reformats and minor cleanups for future commits

No functional changes were intended

Trap expected t/746sybase.t warnings, use LC_ALL instead of LANG

Switch the ::Sybase family to _determine_connector_driver (same as 75d3bdb2)

Simplify test a bit

Fix failing tests with DBICTEST_SYBASE_DSN set

t/746sybase.t - broken by 2a6dda4b
t/storage/quote_names.t - implicitly broken by an oversight in f9b5239a

Sigh

Silence warning introduced in sloppy workaround e9505615

Not sure what I was thinking, but 18637ebb never worked :/

While at it work around the newly-discovered RT#106935

(travis) Pin Sub::Identify until RT#106929 is fixed

Work around EUMM 7.06 creating an empty blib/ dir, breaking prove -lr

Ensure the stack properly deals and warns on Null-Pattern exception objects

Reuse the existing is_exception() utility to catch any and all instances of
objects stringifying to "" before passing them onwards

Enhance exception action test (no functional changes)

Add is_exception check to the result of exception_action (inspired by GHPR#15)

This builds upon work in 841efcb3 and 9bea2000, tying loose ends before next
commits

Read under -w

Merge branch 'current/for_cpan_index' into current/blead

Convert the m2m helper generation to Sub::Quote (as in 8d73fcd4)

This was left for a later time, which is about now, after the multiple passes
through the actual (terrible) code

Read under -w, should contain zero functional changes

More reshuffling of the m2m helper code - no functional changes intended

This is in preparation for the next commit switchin to qsubs

Add missing deprecation warnings on m2m set_*, tighten up code

Back in the day 4d3a827d had the right idea but did not implement actual
deprecation carp()s. Then ac36a402 added support for a link-data arg, making
things even murkier... sigh.

Convert the m2m helper generation to Sub::Quote (as in 8d73fcd4)

This was left for a later time, which is about now, after the multiple passes
through the actual (terrible) code

Read under -w, should contain zero functional changes

More reshuffling of the m2m helper code - no functional changes intended

This is in preparation for the next commit switchin to qsubs

Add missing deprecation warnings on m2m set_*, tighten up code

Back in the day 4d3a827d had the right idea but did not implement actual
deprecation carp()s. Then ac36a402 added support for a link-data arg, making
things even murkier... sigh.

Multiple common sense fixes for m2m accessors

Notably ensure set_X is executed in a transaction, and remove the erroneous
call to _resolve_condition introduced back in 303cf522 and never questioned
since

Expand (and complicate) m2m test from e98e6478

There are no logical changes, the only real addition is the
extra opaque relcond in the middle

Change incomprehensible names of test relationships from e98e6478

No functional changes yet, just renames

Rewrite incredibly overcomplicated add_X m2m helper

Goal was no functional changes, but one never knows - original code was...
rather peculiar

Redo badly named constant folding arg introduced in 8d73fcd4

No functional changes

Streamline (logic-wise, not syntax-wise) handling of 'foreign_values'

No functional changes, just some extra sanity checks

Even though I personally added these in 4f8c9678 I no longer recall why

Switch a couple 'no-brainer' spots to _resolve_relationship_condition

More to come, all of this should result in no functional changes

Remove ability to hand an explicit condition to resolve_relationship_condition

Less moving parts this way, and the only use-cases within the test suite are
all straight from bizarro-land

Read under -w

Make sure array-relconds edge case is handled properly

Hopefully nobody in the wild is using this... hahaha who am I kidding. Anyway
being thorough before subsequent commits

Bring in line behavior of related_resultset() on both $rs and $result

The original problematic behavior on $result was introduced back in 64acc2bc
and never noticed since :(

Minor op reorder in ::ResultSet::related_resultset

This *should* be entirely transparent, but there may be dragons...
Read under -w

Remove no longer needed try{} block in related rel instantiation

This try{} is no longer necessary after 3b4c4d72, but was missed due to
its purpose not being readily apparent. The only known case where this
exception could be raised and be silenced is if an uninserted object had
some filter relations populated directly via {_inflated_column} *before*
related_resultset() has ever been called. This would result in a cascade
of failures during the relationship resolution, and bubble up here.

Starting with 3b4c4d72 the empty related resultset is instantiated ahead
of time, and everything works properly from there on.

In the unlikely case this does cause issues downstream, a way will be
found to address this ( worst case scenario by reintroducing the try{} )

Remove dead code from CDBICompat::ImaDBI

This is a forgotten piece from back in 902133a3, overtaken by a local copy of
Class::DBI::SQL::Transformer. Nothing called/exercised it since then

Simplify and rename _resolve_prefetch

No functional changes, just logic and arglist cleanup - a couple of them were
no longer used: $order was forgotten in d4d8e97b, and the alias-prefix went
unused somewhere around that time as well

Move prefetch selector injection a bit further down in rsattr resolution

No functional changes, just a c/p

Stop importing all the POSIX functions

The only one used is called fully-qualified anyway

Fix t/storage/quote_names.t failures, caused by lazily built sqlmaker

While the entire test is written badly (it ought to use the OptDeps system)
it would be too much churn to fix it properly for little benefit. Additionally
there is a very good chance that the shortener will become a core dep in the
near future, hence the entire point will soon be moot anyway --ribasushi

Add extra (passing) test for operations on sourceless results

This should have been committed with 84b1ec108, reevaluated while reading
through cb909f39c of GH#78

Replace all instances of ; in the rowparser loop with , ( ~15% speedup )

The functional diff best examined via `... --color-words -w lib ...`

This is another microoptimization, which is nevertheless measurable on 1000+
row resultsets. Investigation into this was prompted by a curious comment made
by bulk88[1] in response to Glenn Golden[2]:

  Every ";" is an op that executes that adjusts current line number

Given that we already generate all this code, and it is not intended to be
read by a human, swapping ; with , is only logical. A (very very crude) check
with the included benchmarker indeed shows a repeatable difference on 5.16.2

[1] http://www.nntp.perl.org/group/perl.perl5.porters/2015/05/msg228074.html
[2] http://www.nntp.perl.org/group/perl.perl5.porters/2015/05/msg228068.html

Rewrite collapsing parser while loop (mere op-level golf)

The encode-and-substitute in the generator is not necessary since a8f62ee08

Rewrite the collapsing rowparser pigeonholing logic

Instead of dynamically determining whether to use the data as a key directly,
always compose a list of copied 'row ids' and use that in all operations.

This is mainly done to stop dualvar-ing of numeric variables returned by the
engine, thus confusing JSON and similar serializers down the road

(travis) Add Schmorp's "stable perl" fork to the smoke rosters

A note on motivation: I personally fully support Marc Lehmann's assertion
that the current direction of the perl5 development effort leaves a lot to
be desired (put in the mildest terms possible). The amount of changes[1]
necessary to get a *very* widely used module working again, and the failure
of the original authors to abandon the problematic direction *on their own*
is nothing short of an embarrassment. I fully recognize the reason why Marc
elected to attempt to maintain a fork (a nontrivial long-term commitment),
instead of engaging in another round of politicking and downright begging.

The inclusion of "stability perl" in the DBIC full-test matrix is the very
least I can do to support this effort.
                                                            --ribasushi

[1] http://stableperl.schmorp.de/dist/stableperl-5.22.0-1.001.diff

(travis) Add explicit sudo:true to .travis.yml

The 'sudo' setting now defaults to false on establishing of new github=>travis
linkages, so the CI runs will fail for anyone who wants to smoke their own
fork.

Make sure tests pass without a compiler present (another step to RT#74706)

Make sure tests still pass in a fork-limited environment

Inspired by a temporarily stuck smoker
http://www.cpantesters.org/cpan/report/751da1f2-e3ff-11e4-a1d1-8536eb4f9f07

Read under -w

Make sure plain install with DBICTEST_VIA_REPLICATED=1 still works

This is an omission from fd2c6658, unnoticed all the way until previous commit

(travis) Multiple fixups to the CI lifted from blead:

 - Much lighter CI runs when smoking a PR
 - Revert backout of ODBC firebird testing aa0e82a2
 - Restore and enhance post-success to run a full CPAN install cycle
 - Cut down the amount of APT repos during updates
 - *FINALLY* remove Module::Build::Tiny front-loading
 - Double check M::B::T is not pulled in
 - Peg Module::Install - new versions deps on autodie, which is 5.8.4+
 - Enhance perl sterilization to somewhat work on < 5.12 as well
 - Correctly detect CI on github forks
 - Improve the "Did it really install?" check
 - Better shuffling of the prereq installation order
 - Fix silencer changes (f8200928) which were practically undone by 8b60b921

This is no longer necessary after 4068e05f

Fix missing handling of on_(dis)connect* failures

Time for a short story (see last paragraph for TL;DR): Some hours ago an
innocent question was asked in the #dbix-class channel, apparently
related to a mysterious failure to determine the RDBMS version. Before I
was able to properly investigate the problem, someone else piped up with
"Oh I've seen this before, and I worked around it". That was of course
without telling anyone else </headdesk>

After a little back and forth it became apparent that if the on_connect
settings could not be executed for whatever reason, the result may be an
implicitly failed connection attempt which is *entirely undetected* as
it leaves the original $dbh in place with some or all of the on_connect
instructions not having executed as expected.

To reiterate: if one manages to:
 * supply a malformed on_connect*
and then
 * call as the first order of business some codepath that can mask away
   the connection failure (say ->deploy under sqlite)
then the result is a $schema with a proper $dbh in the storage instance,
but *without* some (or all) of the on_connect instructions having been
executed. As a bonus the actual call to get e.g. the RDBMS metadata (like
version etc) will have failed completely silently as well. Arguably a
rather problematic bug.

The above and by extension an issue with silent on_disconnect* failures
are bith fixed by this commit. This was possible *only* because the
second person came into the channel and reported it, instead of silently
fixing things and moving on to whatever they were doing.

Moreover while preparing the (relatively modest) patch to fix this issue,
a small refactor revealed a pretty serious bug in the XS accessor provider
Class::XSAccessor: https://rt.cpan.org/Ticket/Display.html?id=103296
Yes, it took about 3 hours to diagnose this and hunt down an isolated
failcase, but the bug severety (and its elegance) are totally worth it.

Moral of the story: *PLEASE* report issues upstream. Even if you figured
out a quick workaround, the devs still need to know about the problem you
did encounter in the first place. Bugs that nobody knows about can *NOT*
be fixed, and our software commons can not improve. So *PLEASE* speak up.