FIQL Compliance: filter by just the selector
mckaygraybill opened this issue · 3 comments
Hi, thanks for this cool parser, it's been very easy to use so far. Today I came across something that seems worth bringing up. I haven't read the whole FIQL document yet but noticed that just the selector by itself is valid FIQL:
A FIQL constraint is composed of a selector, which identifies a
portion of an entry's content, and an optional comparison/argument
pair, which refines the constraint. When processed, a constraint
yields a Boolean value.constraint = selector [ comparison argument ]
It is a way to select data in the resource for which that field is present. However, in the readme for this project we find the following:
Comparison is composed of a selector, an operator and an argument.
comparison = selector, comparison-op, arguments;
Indeed, when I specify only the selector and no operator or arguments I get a RSQLParserException (Encountered "" at line 1, column 2.). This seems incongruent with the following quote on the readme:
Since RSQL is a superset of the FIQL, it can be used for parsing FIQL as well.
Maybe there are other parts of FIQL that are not supported in RSQL, I don't know at the moment. Should that wording be changed, or should support for single selectors be added?
I can see how it could be used as a "is not null" check, though that would still leave the "is null" check unsupported by default.
Thanks for pointing to this problem. I don’t remember why I deviated from the FIQL specification in this aspect and I don’t even remember if it was intended.
Should that wording be changed, or should support for single selectors be added?
I’d vote for the latter, but I don’t have enough free time (nor motivation, I admit) to implement this change now. However, I accept pull requests!
I can see how it could be used as a "is not null" check, though that would still leave the "is null" check unsupported by default.
Yeah, that may be a quite elegant way how to test for (not) null.
Thanks for the response! That makes sense. I do have some interest in implementing it, though finding the time is going to be tricky.
Hi,
If I have to support "is null" check, then should I implement a custom operator for the same?