pub fn relation_constraints_for(
comparisons: &[Comparison],
) -> Result<Vec<RelationConstraint>, ParseError>Expand description
Read every constraint on one Relation-typed field, as one group.
The group is the unit, not the comparison, and that is what makes the gate expressible.
Upstream tests query[key], the entire operator document, and then iterates its keys
(DatabaseController.js:1084-1112). So {"$ne": false, "$in": [<pointer>]} passes on the $in
and still processes the $ne, which contributes nothing because its operand names no id.
Evaluating the gate one comparison at a time cannot express that: it either drops the $in
along with the $ne or keeps the $ne along with the $in, and the second is what returned
every owner for a falsy $ne alone.
Returns one entry per operator upstream would build a query for, which is why it is a Vec:
{"$in": [a], "$nin": [b]} is an inclusion and an exclusion, applied independently.
The tag requirement belongs to shorthand equality alone. Requiring it everywhere silently
drops the ids out of a $nin, and an empty exclusion list excludes nobody, so the query returns
the owners it was told to remove.
ACL and CLP still apply to whatever this produces, so getting it wrong widens a result set rather than bypassing authorization. Widening is still wrong.