About filterQuery #1161
Description
In filterQuery we have operators and filters. They are kinda on equal ground. operators work on query part of result, and filters define filters part.
But in AdapterService we see inequality in treatment of those two. Here we see how operators value comes from options.whitelist (and they have unneeded default value), while filters come from options.filters. And while they are both actually lists of additional keys, naming moves focus to whitelist/operators/query part for adapter developers.
Result of this focus you can see, for example, in feathers-mongoose. $populate is a filter type (as it was before changes), but now it is told to go in whitelist and, so, to query part. It results in those manual removals of $populate from query (1, 2, 3, 4), which would not be needed if instead of whitelist, $populate was expected in filters.
Ideally, i think options should have been named operatorsWhitelist/filtersWhitelist, additionalOperators/additionalFilters, whitelistedOperators/whitelistedFilters or something like this. Plus it should be clearly stated somewhere for adapter developers what is the difference between a filter and an operator: the most simple rule is if something has to be at root level and can't be nested in $or or $and (like $populate for example) then it is a filter, otherwise operator.
For starters, we can add aliases to whitelist/filters pair and in next major release remove whitelist/filters.
I know that this is not too important, but still it creates some inconvenience when you can't rely on service.filterQuery to really separate query from filters.
What are your thoughts?