forked from kennknowles/python-jsonpath-rw
-
Notifications
You must be signed in to change notification settings - Fork 83
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
Filter a top level field #66
Comments
Unfortunately, the "specification" for JSONPath is pretty imprecise. I just looked into how to solve this case, but if I make this one working, the previously merged semantics for #41 do not work anymore. The specification doesn't mention anything regarding object access using |
languitar
added a commit
to languitar/jsonpath-ng
that referenced
this issue
Mar 28, 2021
Before this commit, it was not possible to filter on the value of object entries based on their keys such as in the following example Given the input ``` {"foo": 42"} ``` The JSONPath `$[?(@.foo==42)]` did not produce any results and therefore is was only possible to access top-level dictionary entries, but not to produce or not to produce a result at all based on the value of such a top-level entry. This commit implements this feature while trying to keep up all other working path expressions known from the test cases. Interestingly, one test case specifically tried to prevent these semantics (at a deeper level of the document structure). This case had to be removed to make the test suite pass again. I could not find the underlying issue number 2 to find out why this test case existed as that issue seems to stem from a parent of this fork from long ago. Maybe, a resulting release should therefore receive a major version bump as this might be understood as a breaking change. In general, the specification is pretty lose on how square brackets and filter expression are to be understood in the case of dictionaries, not lists. The implementations here follows the already existing practical approach that simply makes more expressions and intended use cases working. However, this results in multiple paths being valid to access the same objects and therefore a ambiguity is created. Fixes h2non#66
languitar
added a commit
to languitar/jsonpath-ng
that referenced
this issue
Mar 28, 2021
Before this commit, it was not possible to filter on the value of object entries based on their keys such as in the following example Given the input ``` {"foo": 42"} ``` The JSONPath `$[?(@.foo==42)]` did not produce any results and therefore is was only possible to access top-level dictionary entries, but not to produce or not to produce a result at all based on the value of such a top-level entry. This commit implements this feature while trying to keep up all other working path expressions known from the test cases. Interestingly, one test case specifically tried to prevent these semantics (at a deeper level of the document structure). This case had to be removed to make the test suite pass again. I could not find the underlying issue number 2 to find out why this test case existed as that issue seems to stem from a parent of this fork from long ago. Maybe, a resulting release should therefore receive a major version bump as this might be understood as a breaking change. In general, the specification is pretty lose on how square brackets and filter expression are to be understood in the case of dictionaries, not lists. The implementations here follows the already existing practical approach that simply makes more expressions and intended use cases working. However, this results in multiple paths being valid to access the same objects and therefore a ambiguity is created. Fixes h2non#66
languitar
added a commit
to languitar/jsonpath-ng
that referenced
this issue
Mar 28, 2021
Before this commit, it was not possible to filter on the value of object entries based on their keys such as in the following example Given the input ``` {"foo": 42"} ``` The JSONPath `$[?(@.foo==42)]` did not produce any results and therefore is was only possible to access top-level dictionary entries, but not to produce or not to produce a result at all based on the value of such a top-level entry. This commit implements this feature while trying to keep up all other working path expressions known from the test cases. Interestingly, one test case specifically tried to prevent these semantics (at a deeper level of the document structure). This case had to be removed to make the test suite pass again. I could not find the underlying issue number 2 to find out why this test case existed as that issue seems to stem from a parent of this fork from long ago. Maybe, a resulting release should therefore receive a major version bump as this might be understood as a breaking change. In general, the specification is pretty lose on how square brackets and filter expression are to be understood in the case of dictionaries, not lists. The implementations here follows the already existing practical approach that simply makes more expressions and intended use cases working. However, this results in multiple paths being valid to access the same objects and therefore an ambiguity is created. Fixes h2non#66
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Given:
The expressions
$[?($.expensive)]
(look for the root/top level expensive field) or$[?($.expensive == "10")]
(check its value) both return:with the Jayway JSONPath (test them on jsonpah.herokuapp.com).
The same expressions return an empty list with jsonpath-ng. Not sure whether this is a bug in jsonpath-ng or its expected behaviour (difficult to say since there's no formal JSONPATH spec).
The workaround is simple though:
The text was updated successfully, but these errors were encountered: