Problem Statement
The filter engine supports equality, $in, and $range, but users cannot write
common one-sided numeric predicates directly. Anyone filtering numeric metadata
has to translate queries like "age greater than 30" or "price less than 20" into
explicit range expressions, which is less ergonomic and easier to get wrong at
numeric boundaries.
Proposed Solution
Add public numeric comparison operators for scalar filters:
The operators should work for integer and float filter fields, preserve expected
equality-boundary behavior, handle negative values and zero, and compose with
the existing AND filter semantics. Boundary cases that cannot match anything,
such as $lt INT_MIN or $gt INT_MAX, should return an empty successful result.
Alternatives Considered
Keep requiring users to express comparison predicates as $range queries. This
avoids adding new operators, but pushes boundary handling and intent translation
onto every client.
Another option is to add only $range helpers in client SDKs. That improves SDK
ergonomics but leaves the HTTP/API contract less expressive and inconsistent
across clients.
Problem Statement
The filter engine supports equality,
$in, and$range, but users cannot writecommon one-sided numeric predicates directly. Anyone filtering numeric metadata
has to translate queries like "age greater than 30" or "price less than 20" into
explicit range expressions, which is less ergonomic and easier to get wrong at
numeric boundaries.
Proposed Solution
Add public numeric comparison operators for scalar filters:
$lt$lte$gt$gteThe operators should work for integer and float filter fields, preserve expected
equality-boundary behavior, handle negative values and zero, and compose with
the existing AND filter semantics. Boundary cases that cannot match anything,
such as
$lt INT_MINor$gt INT_MAX, should return an empty successful result.Alternatives Considered
Keep requiring users to express comparison predicates as
$rangequeries. Thisavoids adding new operators, but pushes boundary handling and intent translation
onto every client.
Another option is to add only
$rangehelpers in client SDKs. That improves SDKergonomics but leaves the HTTP/API contract less expressive and inconsistent
across clients.