-
Notifications
You must be signed in to change notification settings - Fork 5
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
Query satisfied with value from unrelated key #49
Comments
I'm able to work around this issue by wrapping the value in a list, so maybe I'm doing something that JSONPath doesn't expect: fn main() {
let val = serde_json::json!([{"msg_type": 75, "sender": 74}]);
let q = serde_json_path::JsonPath::parse("$[?(@.msg_type == 74)]").unwrap();
let res = q.query(&val).all();
assert!(res.is_empty(), "query should be return no results: {res:?}");
} |
Hey @silverjam - thank you for raising the issue! That certainly looks like a bug and I am able to replicate it in the sandbox. I am open to pull requests; however, I haven't set up a As far as my knowledge of JSONPath is concerned, given the input: {"msg_type": 75, "sender": 74} The query string I would argue, given the structure of the JSON, that the query is malformed, but that does not negate the fact that In this first case producing the bug, we are applying the filter In your second example, the query Unfortunately, in the above two examples, the spirit of JSONPath is not to produce helpful error messages or warnings for malformed queries, but to just produce an empty result. In your final example, when you change the input to an array, i.e., [{"msg_type": 75, "sender": 74}] Then the query works as you might expect. Now, the root node That final case is a more typical use case for JSONPath filters: you have an array of similar objects somewhere in the root node and you want to filter them down based on some criteria. If you want to elaborate more on your particular use case, and why you are using JSONPath, I'd be happy to discuss here. In the meantime, I will go looking into why it is producing false positives, and see if I can get a fix in. |
Hey @silverjam - I believe I have the fix in #50. All tests are green, so I should be able to release before the week is out, but feel free to take a look / review if you'd like. Thank you again for raising the issue, and for putting in the time to share all the details that you did. |
…m-filters [#49] Fix bug producing false positives in filters
@silverjam - |
Cheers! 🙌 |
Hello! Thanks for the amazing work on this crate! I'm super excited to be able to use this crate in one of my projects.
In trying to utilize the crate though I think I've found a bug with how queries work. I believe simple queries such as
$[?(@.msg_type == 74)]
will be "satisfied" by values from unrelated fields.For example, see the following gist: https://gist.github.com/silverjam/b73c6c8ff3f6f5a20e59ad17e234346f
This runs the following code:
You'll note that the query finds the
74
value from thesender
key even though the query should only be against themsg_type
. I'm very new to JSONPath, but I don't think this is intended behavior.The following modification works though (that is, changing the query to
$.msg_type[?(@ == 74)]
):I'd love to be able to help fix this bug if you don't have bandwidth, so if you can provide pointers on where to look I'd be happy to help (if I'm able).
The text was updated successfully, but these errors were encountered: