fix(adapter-commons): Clarify adapter query filtering #2607
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request tries to address some inconsistencies and flexibility issues when implementing and using database adapter.
The problem
There are several issues that mention a lack of clarity when using the previous
filterQuery
method. What is afilter
and what isn't? How are they customized? Another recurring problem is that you may not want strict query filtering when using a database adapter on the server.Improvements
Remove
filterQuery
and addsanitizeQuery
andsanitizeData
This pull request removes the
filterQuery
adapter base service method and adds asanitizeQuery
andsanitizeData
method instead.sanitizeQuery
applies the previous query filters but then returns them as a single query object and it is up to the adapter implementation what to do with that.sanitizeData
does nothing by default but could be used to e.g. filter out protected fields (or things like$push
for MongoDB).Add
$
prefixed unsafe internal service methodsIt also changes the semantics of the
_find
,_get
,_patch
,_update
and_remove
internal (hook-less) service methods to sanitize the query and data and check if multi updates are allowed. It has been moved from the service methods so that it is easier to extend from a database adapter and implement the service methods you need instead of being limited by a type interface (also see #2605).For better flexibility, it additionally introduces the
$find
,$get
,$patch
,$update
and$remove
unsafe internal service methods. This is what a database adapter now implements and it shouldn't do any query or data sanitization. Calling these methods directly lets you do any query the database adapter supports without having to explicitly declare allowed operators, filters ormulti
settings.Clarify
filters
andoperators
Finally all parts of this PR follow a more strict definition of
filters
andoperators
:filter
is a special top level query property starting with a$
. This can be used for pagination ($limit
,$skip
), modifying the result set (e.g.{ $populate: true }
etc.operator
is a special property starting with a$
that can be used to query properties, e.g.{ age: { $gte: 21 } }
This definition has also been reflected in the Querying API documentation.
The adapter settings have been updated and can now be used like this:
Ideally I'd like to see a lot of this responsibility moving to using a query schema and resolvers instead which can handle all those complexities (type coercion, setting dynamic properties etc.) much more cleanly and securely but this is hopefully a step in a better direction.
multi
queries for internal calls only #2546