@dougal83 I added one more feature. PTAL.

@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)

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.

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

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.

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

@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).