Skip to content
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

Merged
merged 1 commit into from
Apr 9, 2019

Conversation

bajtos
Copy link
Member

@bajtos bajtos commented Apr 9, 2019

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.

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

  • New tests added or existing tests modified to cover all changes
  • Code conforms with the style
    guide

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.
Copy link
Contributor

@jannyHou jannyHou left a 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) {
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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!.

Copy link
Contributor

@hacksparrow hacksparrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@b-admike b-admike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👏

@bajtos bajtos merged commit ddd483a into 2.x Apr 9, 2019
@bajtos bajtos deleted the fix/default-value-in-response-2x branch April 9, 2019 16:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants