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.
Rework setup of the Operation Hooks test suite for memory connector
so that the "unoptimized" variant disables not only atomic CRUD
operations, but also geo queries.
This way we can test both "near" querying implementations:
- When the connectors supports "near" queries natively.
- When "near" queries are executed at LoopBack side in-memory.
Fix DataSource constructor to create a shallow copy of the settings
object provided by the caller. This prevents surprising behavior
where changes made to `ds.settings` were picked up by the provided
config object, as observed e.g. in tests of our MongoDB connector.
* Add support for Node.js 12.x (Miroslav Bajtoš)
* fix: coerce primitive properties on update (biniam)
* fix: coerce date array properties (biniam)
* fix: normalize include with boolean or number (spurreiter)
* Improve tests for empty vs. default values (Miroslav Bajtoš)
* Do not apply default values on data from database (Miroslav Bajtoš)
* Update datasource-connector.md (#1703) (Jam Risser)
* feat: support array within array (Hage Yaapa)
* fix: update lodash (#1696) (Janny)
- On include = true or include = 1 the lib crashes with
"TypeError: includes.forEach is not a function".
- checking for boolean and number type and return empty array.
- fix: include symbol and function in normalization
- fix: review changes; adding debug stmt + early exit for tests
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.
Miroslav Bajtoš
spurreiter
Bill Matson
Agnes Lin
Diana Lau
biniam
Biniam Admikew
jannyHou
Janny
Jam Risser
Hage Yaapa
Hage Yaapa