Before this change, when an "access" hook modified the "query" object,
the "near" condition from the original "query" object were still
applied. As a result, the query can end up being more restrictive and
return only a subset of models that should have matched the conditions.
With this change in place, after "access" hook observers are invoked,
we update the "near" condition using the "query" object provided by
hook observers.
Signed-off-by: Miroslav Bajtoš <mbajtoss@gmail.com>
Before this change, two "loaded" events were emitted for every model
instance found. This commit fixes the problem and restores the intended
behavior.
The bug was probably introduced by 5e0c73bec7.
Before this change, when a property was configured with a default value
at LoopBack side and the database was returned a record with a missing
value for such property, then we would supply use the configured
default.
This behavior is problematic for reasons explained in #1692.
In this commit, we are fixing DAO operations like `find` and
`findOrCreate` so that they do NOT apply default property values on
data returned by the database (connector).
Please note that most of the other CRUD methods were already not
applying default values on database data as long as the connector
provided native implementation of the operation.
The new version of our config enabled function-paren-newline rule,
this commit fixes the codebase to use more consistent handling
of newlines when calling functions.
Fix the regression introduced by 9af79cf51a where updateAttributes
and replaceAttributes was incorrectly handling the response returned
by the database.
This commit restores the old behaviour where `context.data` is updated
only by a connector-provided function and reverts an incorrect change
of a test file made as part of the faulty fix.
Besides the fixes, this patch also renames `data` to `dbResponse` and
add comments explaining the structure of the response object for more
clarity.
Before this change, many Operation Hooks were not correctly propagating
changes made to `ctx.data` via reassigning ctx.data to a new object.
This change modifies existing tests to account for this different
scenario, adds few more tests for scenarios that were not covered by
tests before and finally fixes the problem discovered.
* updateOnly, forceId changes
* support getUpdateOnlyProperties
* fixup! fix updateOrCreate in forceId mode
The contract of `updateOrCreate` is expecting a full object instance
to be passed to the callback.
The current implementation was creating an empty instance and
calling updateAttributes under the hood. As a result, the callback
was called with the attributes being updated only.
In order to preserve existing behaviour, we have to always build
a full initial instance by calling `findById`.
See the following discussion for more context:
https://github.com/strongloop/loopback-datasource-juggler/issues/966
* fixup! fix tests of upsert validation
* move forceId to model-builder
* remove TODO comment
* revert refactoring and test fixes
* Remove duplicate test
* change testcase names
* change to ModeClass.settingse
* forceId setup from datasource to model-builder
* fix inheritance of auto-generated forceId
* Fixed failing tests for auto change
* fixed a comment
Miroslav Bajtoš
Agnes Lin
biniam
Raymond Feng
leon3s
Dimitris
Tom Kirkpatrick
virkt25
Kevin Scroggins
Jürg Lehni
Rashmi Hunt
loay
Raymond Feng
ssh24
Joshua Chaitin-Pollak
Jonathan Sheely
Mikhail
Diana Lau
Kevin Delisle
Rémi Bèges
Miroslav Bajtoš