Open mckaygraybill opened 6 years ago
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?
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:
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:
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:
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.