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

feat: simplify filter and where usage for constraint, schema, and OpenAPI mapping #4745

Merged
merged 6 commits into from
Feb 28, 2020

Conversation

raymondfeng
Copy link
Contributor

@raymondfeng raymondfeng commented Feb 25, 2020

Fixes #1721, #3336, and #1749

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

  • npm test passes on your machine
  • New tests added or existing tests modified to cover all changes
  • Code conforms with the style guide
  • API Documentation in code was updated
  • Documentation in /docs/site was updated
  • Affected artifact templates in packages/cli were updated
  • Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

Copy link
Contributor

@dougal83 dougal83 left a comment

Choose a reason for hiding this comment

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

Looks good. 👍

@raymondfeng raymondfeng changed the title feat: add type and schema for filter excluding where for findById feat: simplify filter and where usage for constraint, schema, and OpenAPI mapping Feb 26, 2020
@raymondfeng
Copy link
Contributor Author

@dougal83 I added one more feature. PTAL.

@nabdelgadir
Copy link
Contributor

@raymondfeng I'm a bit confused about why we're excluding where in findById calls. I understand from #3336 that it's being ignored, but do we want to ignore it rather than allow restrictions through it on findById calls (e.g. returning undefined if it doesn't match the restriction)?

(also there's a typo in the second commit message, excldue -> exclude)

@raymondfeng
Copy link
Contributor Author

I'm a bit confused about why we're excluding where in findById calls. I understand from #3336 that it's being ignored, but do we want to ignore it rather than allow restrictions through it on findById calls (e.g. returning undefined if it doesn't match the restriction)?

The rationale behind findById is to look up a record by its primary key (id). No other search criteria should be used. If a client wants to search beyond id, use find or findOne instead.

Copy link
Contributor

@nabdelgadir nabdelgadir left a comment

Choose a reason for hiding this comment

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

The rationale behind findById is to look up a record by its primary key (id). No other search criteria should be used. If a client wants to search beyond id, use find or findOne instead.

Ah, I see. Thank you for the explanation 👍

@derdeka
Copy link
Contributor

derdeka commented Feb 27, 2020

The rationale behind findById is to look up a record by its primary key (id). No other search criteria should be used. If a client wants to search beyond id, use find or findOne instead.

@raymondfeng
Thanks for explanation. I did not know this before.
To clarify this for developers, maybe we can add this rationale here?:
https://github.com/strongloop/loopback-next/blob/2e52f355f95cee82b5401bfa2bcbbf6ccc5a91d2/packages/repository/src/repositories/repository.ts#L173-L181

Copy link
Member

@achrinza achrinza left a comment

Choose a reason for hiding this comment

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

Other than @derdeka's comments, everything else LGTM 👍

Copy link
Member

@bajtos bajtos left a comment

Choose a reason for hiding this comment

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

Personally, I think it's a better design to allow callers of getFilterSchemaFor and @param.filter to provide {excludeWhere: true} when they want to remove where from the schema, I find it more extensible and future-proof.

Having said that, it's something we can implement in addition to what's proposed in this pull request. I see there have been already view approvals, I am ok to go with the crowd.

@raymondfeng raymondfeng force-pushed the fix-1721 branch 3 times, most recently from 2c2b093 to a0e2e6e Compare February 27, 2020 18:18
@dougal83
Copy link
Contributor

Personally, I think it's a better design to allow callers of getFilterSchemaFor and @param.filter to provide {excludeWhere: true} when they want to remove where from the schema, I find it more extensible and future-proof.

@bajtos +1 If given a preference I would prefer to use this approach that you've given. While either way will work it is neater to use an option.

@raymondfeng
Copy link
Contributor Author

@dougal83 The PR has been refined to address the review comments. PTAL.

exports[
`lb4 relation checks generated source class repository answers {"relationType":"belongsTo","sourceModel":"Order","destinationModel":"Customer"} generates Order repository file with different inputs 1`
] = `
exports[`lb4 relation checks generated source class repository answers {"relationType":"belongsTo","sourceModel":"Order","destinationModel":"Customer"} generates Order repository file with different inputs 1`] = `
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: double space after repository?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I'll move this commit to a separate PR. The snapshot is generated. If we need to fix the prompt, we should fix cli.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See #4761

@raymondfeng raymondfeng force-pushed the fix-1721 branch 2 times, most recently from 31177ff to 137aa2d Compare February 27, 2020 20:23
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.

👍 Nice to have the shortcut!

Copy link
Member

@bajtos bajtos left a comment

Choose a reason for hiding this comment

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

Awesome, I find the new implementation so much simpler and also more flexible 💪

I have few comments on details that could be improved, see below.

Copy link
Contributor

@deepakrkris deepakrkris 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
Copy link
Member

bajtos commented Feb 28, 2020

@raymondfeng Feel free to merge the PR after my comments are addressed, no need to wait for another review from me (unless you want to).

@bajtos bajtos added developer-experience Issues affecting ease of use and overall experience of LB users feature labels Feb 28, 2020
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.

👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer-experience Issues affecting ease of use and overall experience of LB users feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for "include" and "fields" to findById (REST API)
10 participants