Add support for operators in the @QuerydslPredicate-generated predicates [DATACMNS-905]

Milan Milanov opened DATACMNS-905 and commented

This will allow for more advanced filtering of the data returned. The filtering API definition heavily borrows from here.
\
\
The general format of a query syntax could be as follows:
/api/v1/resource/field_name=op:value (or op|value or whatever)
\
\
field_name - The name of the field that will be compared against.
op - (Optional) The comparison operator to use when comparing the specified value to the field. Defaults to eq.
value - The value being checked for.(empty line)
\
\
Examples:
/api/v1/products?item_name=test
/api/v1/orders?ordered_at=gt:2012-12-08T06:00:00.0Z
\
\
As a start only the most "basic" operators could be added, i.e. eq, neq, gt, gte, lt, lte, in, nin (as in not in). I'm aware of DATACMNS-846, but I think this proposal doesn't have the issues mentioned in the first - no ambiguity between operators and nested properties and the internals can be changed if needed (not that tight coupling). I think i've located the code responsible for the predicate building (QuerydslPredicateBuilder) and would be happy to try to submit a PR if the proposal is accepted (and with some general guidance of course)

4 votes, 4 watchers