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

fix(range-bounds): observe inclusive range bounds #9364

Merged
merged 3 commits into from May 7, 2018

Conversation

@mjy78
Copy link
Contributor

@mjy78 mjy78 commented Apr 27, 2018

Pull Request check-list

Please make sure to review and check all of these items:

  • Does npm run test or npm run test-DIALECT pass with this change (including linting)?
  • Does the description below contain a link to an existing issue (Closes #[issue]) or a description of the issue you are solving?
  • Have you added new tests to prevent regressions?
  • Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
  • Did you follow the commit message conventions explained in CONTRIBUTING.md?

Description of change

Ensure the 'inclusive' property on range bounds is not lost when querying.

Closes #8176, #8471

@codecov
Copy link

@codecov codecov bot commented Apr 27, 2018

Codecov Report

Merging #9364 into master will not change coverage.
The diff coverage is 100%.

@mjy78 mjy78 force-pushed the mjy78:master branch 3 times, most recently from 9f9ec8f to a6e10ab Apr 28, 2018
@mjy78 mjy78 force-pushed the mjy78:master branch from 3b7b1f7 to 0d9a387 May 2, 2018
@@ -130,6 +130,13 @@ exports.formatNamedParameters = formatNamedParameters;
function cloneDeep(obj) {
obj = obj || {};
return _.cloneDeepWith(obj, elem => {
// Special handling for the inclusive array property (for range types)
if (Array.isArray(elem) && elem.hasOwnProperty('inclusive')) {

This comment has been minimized.

@sushantdhiman

sushantdhiman May 2, 2018
Contributor

This will execute for each clone operation I would like to avoid this if possible, there is also one more issue #8471

As you are using this type in real world, what do you think about having range type store values like

[{  
  value: 10,
  inclusive: true
}, {
  value: 10,
  inclusive: true
}]

Rather than having non-standard array property?

This comment has been minimized.

@mjy78

mjy78 May 3, 2018
Author Contributor

I agree that not having to worry about special handling for the non-standard "inclusive" array property would be much cleaner. We should move to a standard representation of range types for both query predicates and query results ensuring the inclusive property is still maintained when results are converted to JSON.

This will be a breaking change though, as we (and I expect many others) have a lot of code that expects range values returned in query results to be of the form

[ 10, 10 ]

Another approach might be to allow range types to have a 3rd "options" element in the array. When querying/inserting you could define your range as any of

[ 10, 10 ] // Defaults to inclusive [true, false]
[ 10, 10, { inclusive: true }]
[ 10, 10, { inclusive: [ true, false ] }]

Query results would always be returned as

[ 10, 10, { inclusive: [ true, false ] }]

This will still be a breaking change, but may lessen the impact on those queries that currently use ranges in their default form (without being concerned about inclusivity).

This comment has been minimized.

@sushantdhiman

sushantdhiman May 3, 2018
Contributor

As we are under v5 beta process I would prefer just do one time switch to proper format, which will solve both clone and stringify issues

[{  
  value: 10,
  inclusive: true
}, {
  value: 10,
  inclusive: true
}]

This comment has been minimized.

@mjy78

mjy78 May 3, 2018
Author Contributor

No problem. Is it ok if I make these changes under this pull request? There'll be some documentation changes too which I'll try to cover.

This comment has been minimized.

@sushantdhiman

sushantdhiman May 3, 2018
Contributor

Yeah no problem

Copy link
Contributor

@sushantdhiman sushantdhiman left a comment

Looks good, just a small documentation change

```

Make sure you turn that into a serializable format before serialization since array

This comment has been minimized.

@sushantdhiman

sushantdhiman May 7, 2018
Contributor

A note here saying that you will need to call reload after updating an instance with range type or use returning: true option

This comment has been minimized.

@mjy78

mjy78 May 7, 2018
Author Contributor

Done.

@sushantdhiman sushantdhiman requested a review from sequelize/orm May 7, 2018
BREAKING CHANGE: range values are now returned as an array
    of two objects with each containing a property for the value and
    a property for its bounds inclusion, rather than bounds inclusion
    being defined as an array property. When inserting/querying,
    bounds inclusion must also be defined in the same way.

    This change ensures that bounds inclusivity is not lost when
    serializing or logging data returned in query results.

    To migrate code, follow the example below:

    Before:

    range: [10, 20];
    range.inclusive = [false, true];

    After:

    range: [{ value: 10, inclusive: false }, { value: 20, inclusive: true }];

Closes #8176, #8471
@mjy78 mjy78 force-pushed the mjy78:master branch from 36dfd22 to fbb99d9 May 7, 2018
@sushantdhiman sushantdhiman requested a review from sequelize/orm May 7, 2018
@sushantdhiman sushantdhiman merged commit b66f9dd into sequelize:master May 7, 2018
4 checks passed
4 checks passed
codecov/patch 100% of diff hit (target 95.94%)
Details
codecov/project 95.94% (+0%) compared to bd6fa21
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants