Proper end-of-file for DBIx/Class.pm

Add forgotten bit preventing scan of where-binds (originally part of 1b8f2dd9)

Add basic .dir-locals.el

(travis) Attempt to revert 86370cc74, SC is too slow on uptake. Grumble

Properly handle empty group_by/order_by

Improve SQLT::Parser warning messages (build further upon e089c417)

Properly implement very sloppy and lazy hack from bad0b73b

We are abusing local() here - might as well abuse it correctly.
This way we do not add a permanent shitty name to the relinfo structure and
nobody needs to fix their tests. Winning!

Revert e9f71ab2 - it ends up breaking a declared API

I should have thought of this earlier - a debug object is not necessarily
isa(IO::Handle) (the documentation never mentioned this). And indeed: the
tests of DBIx::Class::QueryLog do exactly this - they use an object with
just a print() method and absolutely nothing else.

So instead of disabling the sticky autoflush (which really is only a visible
change on STDERR dup) document this behavior and move on.

Fix broken temporary backcompat shim for naughty _resolve_condition callers

The 9b96f3d41 refactor undid all the backcompat shims that were introduced
in c0f445097. Reinstate the insanity until after 28...

Multilevel find_or_(multi)create got inadvertently broken

Relax the check of what we feed to the relcond resolver

Yet another loose end on the cond collapser

Fingercross this is the last one... this transform is turning out ot be a
bad bad bad idea :(((

Ensure the tempextlib is available at distbuild time

Missed one spot to load ::_Util during bbcc1fe8

Put in place deprecation forgotten for several years

More info and rationale in the commit msg of c200d949

Split DBIC from SQLMaker test (deprecated in next commit)

Ensure the custom rel cond resolver does not trigger forgotten compat shim

During the rush to get custom rels out the door (this is why rushing
fucking sucks), a697fa31 introduced a shortsighted workaround into
::SQLMaker::_from_chunk_to_sql(). This code slipped consequent review
and made its way into the codebase... 4 FUCKING YEARS AGO!!! >:(

Since it is not known how much stuff relies on the insanity being there
(moreover we have tests that rely on it) leave things as is for the time
being. The only change is  making the cond resolver *completely* oblivious to
the "single-element hash" workaround (albeit via a silly hack).

In the process exposed that ora-joins module is entirely incapable
of understanding non-equality conds... fml

See next commits for added warnings, etc.

A more robust column equality extractor

It is a mistake to reach into $ret->{condition} - it may very well be a
non-hash structure. Also replace the silly regexping with the (already
regexed out) results of the info resolver

Ensure undef_on_null_fk does not affect non-introspectable custom conds

Yet another missed sanity check in the relcond resolver

rel/col duality is just hateful

Make sure the me-relname-flip does not affect any error text

Fix copy() assuming all columns are native

Adjust for SQLA's API change 966200cc8

(travis) Accommodate a slow mirror grrrrr

(travis) Stop auto-upgrading everything on non-clean installs

It adds little value currently and makes version-specific installs difficult
(see next commit)

Fix syntax error in ::Manual::Joining example

fixed syntax error on line 245 (missing closing curly bracket)

Closes: #60

Fix incorrect cond construction in _minimal_valueset_satisfying_constraint

The function in question introduced in d681f1bb (which builds upon work in
8e40a627) correctly uses _extract_fixed_condition_columns, but then fails to
account for all literals having their leading { '=' => ... } being stripped,
nor does it consider UNRESOLVABLE_CONDITION as a valid return value.

Tests and fixes to get this rolling, thanks go to Lianna Eeftinck for testing
and reporting \o/

Ensure ::Schema::Versioned connects only once by reusing the main connection

Stop using Sys::SigAction in pg tests

Fix for gut-reaching travesty as reported by gbjk

No longer use rel_info($rel)->{class} in the cond resolver

It turns out there are a lot of codebases there containing garbage in the
rel definition. Punt for after 0.082800 to lean up that mess.

Also be less strict on checking the foreign_values contents - downgrade
mismatches to a warning (but still hard-require ::Row ancestry)

Simplify self_result_object argument check in cond resolver

Minor relcond resolver refactor, no func. changes

Skip malformed relationships in SQLT parser instead of vague warnings

Move and simplify a chunk of parser code

No functional changes

Make sure IO::Handle is loaded - missing stubs on older perls

Also adjust the documentation in the wake of the e9f71ab2a change

Make sure the resolve_cond shim attempts to lint the right thing

This only matters in compat mode, so sod testing

(travis) Sorry metacpan, your mirror is simply shit >:(

Changelog for RT#98161

Breakage introduced in 8d005ad9, fixed for good by a combination of 5268b1da
135ac69d and 95da0f23

Better describe the _resolve_relationship_condition API

Add one more spot of unroll

One more fail-case missed in 135ac69dd

Now the test attached to RT#98161 actually passes... le sigh

At this point I am very wary of the entire codepath: yes, it is clearly the
right thing to do, and the logic is sound, but odd edge cases keep popping
up like this... OTOH there is no way to properly do equality inferrence
without this entire dance, in other words: rock&hardplace. Hopefully the
test suites will shake this out, apologoies to all affected :(

Better optional diag in t/sqlmaker/dbihacks_internals.t

Fix condition collapser corrupting -X operators

This is (fingercross) the complete fix for RT#98161

Make sure empty cond collapser works on all positions

Adds another round of sql stabilization (akin to 5268b1da6)

Make sure cond collapser works case insensitively

Deduplicate (and stabilize) the result of _collapse_cond

Among other things set the stage to a fix of RT#98161 (later commit)

Switch to a sane deduplication system

The original naive approach from 8e40a627f was utterly braindead and prone
to false positives. Fix this for good

Remove a superfluous pair of []s in cond collapser

Fix "muse" typo in Relationship::Base's POD.

Update 'as' vs '-as' discussion in ResultSet.pm

Call me pedantic, but I think moving the statment to a new line makes it
more prominant. I may have seen it before heading to irc to ask why it's
broken. Yes I should have read the section fully, but I didn't.

Also made the two statements use the same terminiolgy to be consistent
and add context.

Reword the having attribute reference

Add extra doc line expanding on the role of the prefetch attribute

Ensure the TempExtlib actuall exists

S::L tests rely on preserving the sqlmaker between reconnections

While this is utterly retarded, punt and backout the b6a469f7 change for now.
Will revisit again during the connect_info consolidation

Tighten the 'txn-op on disconnected handle' checks

Simplify some ::Storage::DBI methods (no tempvars)

No functional changes at all

Fix $rs->populate with column name array but no row data

Two regressions for both context types snuck in during the the big populate()
rewrite d0cefd99

- In scalar context the return value incorrectly went from () to []
- In void context an empty $data was handed to ::Storage::_insert_bulk

Deprecate insert_bulk - we will be changing its signature down the road

Besides there is really no reason for users to call it directly

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