-
Notifications
You must be signed in to change notification settings - Fork 49
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
Wrong identifier #71
Comments
This is not possible in RQL, please see issue #51. I'm working on a solution for this, and will post it soon. |
Thank you for your response. Is Otherwise users type This seems simple in this example, but in more complex queries it becomes very hard to see what's wrong. Thanks again, |
@ozum more complex queries are possible in a Turing-complete query language, for instance xquery. AFAIK this was never the goal of RQL. Even if you could write the kind of queries you propose, at some point you'd want to create temporaries and the whole shebang (to not have to type in sum(price) multiple times)... I don't think you should always expose the entire query to the user though, as that could indeed lead to unexpected results, and might even be considered unsafe in some cases. I usually create a mapping between URI fragments and complex queries. In other words: always provide users with a bunch of understandable links. |
Thank you. |
I feel that the core issue here is that there are actually two kinds of "operators" in RQL: those that evaluate as a logical sentence for filtering entries in a collection (i.e. true/false predicates) and those that mutate the behaviour / output format of the retrieval in other ways. In my opinion, those should be always kept separate: it is probably pointless to perform a logical "or" on sorting or aggregation directives. Thus, I consider these "non-logical" operators as more of commands, really. To be fair, RQL bugs me a bit because it mixes the two in a single query string (and, in fact, under a common logical AND predicate). Indeed, I find that there is an implicit parity between what MongoDB (lacking an expression language) can do, and what RQL may represent. Example: in MongoDB, you can do This may need clearing up in the README. A separation between things that count as predicates and those useful for sorting/limiting/aggregation etc. would also be welcome. |
@rkaw92 I agree. Syntactically it would be correct to add a filter() function, which evaluates the filter. This is indeed how functions are evaluated, as anything but the filter operators is considered top-level. I'd add this to the parser, but it would break compatibility, so instead I suggest adding a normalization that wraps operators in a filter(), so we can move towards a Turing-complete RQL. |
Oh, I think I misrepresent my question, I try to rephrase it: As my understanding of RQL documentation, those two queries are equal RQL queries:
I expect RQL parser generates identical AST for those equal queries, but RQL parser generates two different AST for those equal queries. There are two possibilities: Best Regards, |
Hi,
sum(price)=gt=3
query generates following object:Shouldn't it be like
gt(sum(price),3)
Or at least it may throw exception.
Best Regards,
The text was updated successfully, but these errors were encountered: