* knex methods are proxies for context methods ...
... as opposed to injecting the methods directly onto the knex
function. (Which was then causing `this` to point to the wrong
object when evaluating the context methods)
* Moved CONTEXT_METHODS constant to a higher scope
* mv knex.context -> this.context
* Extracted KNEX_PROPERTY_DEFINITIONS to module scope ...
... which was possible since all of the properties reference
`this` instead of `knex` now
* shallowCloneFunction no longer accesses _context ...
... instead, it uses the normal context property
* transaction method delegates to _transaction ...
... This way, we can be sure that the lower-level details are
consistent across implementations. Individual implementations
just need to handle the quirks around setting up the `config`
and `outerTx`
* CONTEXT_METHODS shared. Fixed override of withUserParams ...
Restructured the code so that CONTEXT_METHODS populates the
KNEX_PROPERTY_DEFINITIONS with the proxy methods.
In doing so, it also exposed the fact that the withUserParams(..)
method was being overridden on the Transactor instead of its
context. So, that bug was fixed as well.
* Added a TODO to remove client.makeKnex(..) in future PR
* Added a warning about QueryBuilder.extend(..) and side-effects
* Transactions initialize their own _lastChild placeholder ...
... rather than initializing the _lastChild on their outerTx
* Transaction initialization logic no longer needs to be stalled
* Extracted _previousSibling logic out of _evaluateContainer
* Transaction logic establishes 2 separate Promise Chains...
... One chain is for INTERNAL use within the Transaction logic
itself. This chain ignores exceptions. It is simply used to
signal when the "Next Transaction" (sibling) is allowed to begin.
The other chain is for EXTERNAL use. It expects the caller
to handle any exceptions that occur during the Transaction.
The underlying issue was that query *always* committed, even during a transaction. The previous fix was to just disable commitAsync in a transaction but then that also disabled explicit commit calls. Instead, this fix disables query's commits during transactions so that explicit commits still work.
cancelQuery(..) was attempting to
"cancel the cancellation" after 100ms. However, it was not
actually achieving this objective. In reality, the cancellation
was still running in the background even though the caller had
already moved on.
Later on, the cancellation would ACTUALLY fail due to a resource
allocation issue (ie: no more connections in the Tarn pool).
This would then result in an unhandled Promise rejection.
