You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The query object specification only has limited ways to match against document fields.
For example, we have lowPath which does <= and highPath which does >. What if we want to do < or >=?
We need to add timestamp range queries too. Do we need a combinatorial explosion of query parameters?
Generalized query options for matching document fields
A more systematic way to do this is to combine a field and an operation:
letquery={timestamp_lte: 15000000000,// timestamp less than or equal topath_prefix: "/wiki/",// path has prefixauthor_in: ["@suzy.bxxxx","@matt.bxxxxx"],// author in listcontent_neq: "",// content !== ""}
Operations:
< lt
<= lte
> gt
>= gte
== === eq // this is the default if no operation is specified
!= !== <> neq
prefix or startsWith
suffix or endsWith
in
Symbols or letters? Spaces or underscores?
{
// which style is better?
timestamp_lte: 15000000,
"timestamp <=", 15000000,
}
This would make for quite a large Query type. Luckily the code doing the query could handle this in a generalized way by splitting the properties at _ instead of hardcoding each combination.
What's the problem you want solved?
The query object specification only has limited ways to match against document fields.
For example, we have
lowPath
which does<=
andhighPath
which does>
. What if we want to do<
or>=
?We need to add timestamp range queries too. Do we need a combinatorial explosion of query parameters?
Generalized query options for matching document fields
A more systematic way to do this is to combine a field and an operation:
Operations:
Symbols or letters? Spaces or underscores?
This would make for quite a large Query type. Luckily the code doing the query could handle this in a generalized way by splitting the properties at
_
instead of hardcoding each combination.Other query options stay the same
Some query options are not about matching specific fields. These would continue to work in the old way, without an operation in the property name:
Queryable metadata
If we implement #9 we would also need to query the metadata keys and values. Maybe like this?
The metadata we want to search for:
The query:
The text was updated successfully, but these errors were encountered: