there is no support for contains. We are
there is no support for contains. We are planning add support for the following operations:
- greater than
- greater than or equal
- less than
- less than or equal
- in s specified array
- not in a specified array
4 Replies
exist (contains) will probably comes last
Hello yevgen, it's great news that this is coming.
How could I achieve a similar result today for 'not in a specified array'?
or
or
Because the 2nd isn't valid JSON (object with non-unique keys), but the docs don't have an example with an array (so I dunno if it's possible).
And the 3rd one seems like what you guys are building, but probably isn't supported with the '$ne' operator. Edit: I've confirmed with the
worker.types
, indeed the filters don't support string[]
😭Hi there! Only the second proposition should produce a result, but not the one you'd like in that case, as it's going to consider only the last instance of the metaId filter. None of these is a subsitute for $nin (the operator for "not in a specified array" as per your request would be
"$nin":[...]
and not "$ne":[...]
if there was first party support for it)Thanks for getting back to me 🙏
I've gone ahead and picked the filter which I believe would filter out most of the results and I run a 2nd query with that filter on...
I'll write some comments in the code that specify how we should change it whenever the
$nin
operator becomes available.
(actually, in theory, we should be able to have both codes live... we simply check if the operator exists, if it does, great, it 'auto-upgrades', and if not (until it happens) it uses the legacy system).