-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not apply default values on data from database [2.x] #1706
Conversation
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢 LGTM
// And findOrCreate an existing record | ||
return Player.findOrCreate({id: created.id}, {name: 'updated'}); | ||
}) | ||
.then(function(result) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: I like the spread()
function used in the original PR #1705, any reason switched back to then()
?
Not a blocker for merging, just curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In LB 3.x, we are using Bluebird as the promise library, therefore .spread()
is available on all Promise instances.
In LB 2.x, we use the native Promise library if it's provided (Node.js 4.0 an higher), and require users to set global.Promise
to any compatible Promise implementation on Node.js versions 0.10 & 0.12. The native Promise does not provide .spread()
API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I see. makes sense thanks!.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👏
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 likefind
andfindOrCreate
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 valuenull
does not trigger application of default values. This is important because SQL connectors returnnull
for properties with no value set.Related issues
This is a back-port of #1705, which is a backport of #1704. Compared to #1704 (master/4.x), we are preserving backwards compatibility by introducing a new feature flag.
See also #1692.
/cc @sharathmuthu6 @snarjuna
Checklist
guide