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>
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 primitive datatypes coercion [3.x]
Make sure we coerce Date values properly when creating new
model instances. Also make sure we use the coerced data values
for model instance for update operation.
- 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
* Do not apply default values on data from database (Miroslav Bajtoš)
* feat: support array within array in 3.x (Hage Yaapa)
* feat: Support "type" key in sub-properties in 3.x (Hage Yaapa)
* fix: use existing field in exclude test (biniam)
* eslint: manually fix remaining problems (Miroslav Bajtoš)
* eslint: autofix linting errors (Miroslav Bajtoš)
* eslint: upgrade eslint-config-loobpack to latest (Miroslav Bajtoš)
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 introducing a new model-level setting called
`applyDefaultsOnReads`, which is enabled by default for backwards
compatibility.
When this setting is set to `false`, operations like `find` and
`findOrCreate` will NOT apply default property values on data returned
by the database (connector).
Please note that most of the other CRUD methods did not apply default
values on database data as long as the connector provided native
implementation of the operation, that aspect is not changing.
Also note that default values are applied only on properties with
`undefined` values. The value `null` does not trigger application of
default values. This is important because SQL connectors return
`null` for properties with no value set.
Nora
Nora
Diana Lau
Bill Matson
Miroslav Bajtoš
biniam
Biniam Admikew
Janny
spurreiter
jannyHou
Hage Yaapa
Hage Yaapa
Raymond Feng
leon3s