Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIQL Compliance: filter by just the selector #28

Open
mckaygraybill opened this issue Dec 12, 2017 · 3 comments
Open

FIQL Compliance: filter by just the selector #28

mckaygraybill opened this issue Dec 12, 2017 · 3 comments

Comments

@mckaygraybill
Copy link

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.

@jirutka
Copy link
Owner

jirutka commented Dec 28, 2017

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.

@mckaygraybill
Copy link
Author

Thanks for the response! That makes sense. I do have some interest in implementing it, though finding the time is going to be tricky.

@juliekjoy
Copy link

Hi,
If I have to support "is null" check, then should I implement a custom operator for the same?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants