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

Allow filtering dictionaries using entry keys #74

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

languitar
Copy link

@languitar languitar commented 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 #66

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Filter a top level field
1 participant