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

Optionally return path to item instead of item itself #29

Open
gregsdennis opened this issue Feb 17, 2020 · 7 comments
Open

Optionally return path to item instead of item itself #29

gregsdennis opened this issue Feb 17, 2020 · 7 comments

Comments

@gregsdennis
Copy link
Collaborator

gregsdennis commented Feb 17, 2020

Goessner's original post declares that the return type (array form) could either be the found items or the JSON Paths to those items. Is there any intent to check for this kind of output in the future? Have you seen any libraries support this?

return value:
(array|false):
Array holding either values or normalized path expressions matching the input path expression, which can be used for lazy evaluation. false in case of no match.

@remorhaz
Copy link
Collaborator

My remorhaz/php-json-path supports returning paths (with one of these methods of processor). But I don't think that checking this behaviour is of big value: the main problem is that different implementations select different values, not paths.

@cburgmer
Copy link
Owner

We could include it in the scope.
I would probably only invest if enough libraries support this operation and there's a tendency to agree on a similar response type.

I know of the Clojure implementation also supporting this, as I implemented it 3 years ago :)

@remorhaz
Copy link
Collaborator

But what we should check in this case? For example, implementation X returns $.a.b, and implementation Y returns $["a"]["b"] as a path string. The expressions are different, but they do the same work and return the same value.

The question is - is there any reason for the paths not to be different?

@cburgmer
Copy link
Owner

If we see that response formats are different, we might be able to write a trivial transformation.

As for why answers should be different, I would expect less deviation once the actual JSONPath responses are aligned. However I wouldn't rule out misalignment there either, I'm always surprised what I find once I dare to check.

@gregsdennis
Copy link
Collaborator Author

Maybe it's sufficient to just have a check to see if it's supported for a given library.

If the unit JSON has unique values, then testing on the values returned would be good enough to know that the query did what we expect.

From there, it's a reasonable assumption that the paths to the values would be correct.

@danielaparker
Copy link
Collaborator

danielaparker commented Mar 9, 2020

Goessner, when discussing dot notation and bracket notation, says that "...output paths will always be converted to the more general bracket–notation", which suggests the correct return value would be $['a']['b'], not $.a.b.

@gregsdennis
Copy link
Collaborator Author

gregsdennis commented Oct 20, 2020

While I understand the tendency to use JSON Path for the locations (seeing as that's what we're building, which is likely why Goessner suggested it), I don't think that it's appropriate for this use case. JSON Pointer is more appropriate here since it's designed to isolate and identify a single value from a document. JSON Path is a query syntax and returns an array of values.

JSON Pointer is an extremely simple syntax that's already in spec and has wide library support.

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

No branches or pull requests

4 participants