Results do not match other implementations about jsonpathkt HOT 5 CLOSED

Thank you for the issue, the 1st and 3rd ones will be addressed in the next release: 2.0.0. I'll be switching to Jackson since it allows me to preserve the order of object keys when the JSON is deserialized.

The second one will be kept as designed. My current implementation is more useful in my opinion because it allows for consistency. If I change to only return the values for $['key','another'] and the JSON object is missing key key, then it will only have 1 value and user won't know if the value is from key or another. Also, keeping the keys allows me to easily convert the result to data class (also new addition to version 2.0.0). Additionally, if I REALLY want the values, I'm thinking one can add .* to the jsonpath to get those values. I will implement this token too.

2.0.0 is in the dev branch at the moment. I'm going to go through your project and see what other paths I should tackle to be more consistent with other implementations before I release.

from jsonpathkt.

Thanks for this, I really like the page you have showing the differences at https://cburgmer.github.io/json-path-comparison/

I'll take a look at some of these and others in your table over the next several days.

from jsonpathkt.

I took a look at the ones you listed in this issue.

1. The first one $[:] looks like a crash which I'll fix. I may as well support it too.

2/3) The second and third ones are based on implementation. I use org.json which intentionally uses a hashmap because the JSON spec says object key order cannot be guaranteed and should not be relied upon. I think Jackson by default also doesn't guarantee order here. With that said, I don't believe the third one is an issue otherwise I'd have to ditch org.json and go with a different parser 🙁
EDIT: I saw you have an issue created for yourself asking if order is guaranteed on a similar path of $..key for jsurfer, whereas mine happened to be match others for this path (cburgmer/json-path-comparison#3)

2. For the second one in particular, I'll have to say that I disagree with the consensus result given and prefer my output. Being that JSON object key order isn't guaranteed, a path like $['key','another'] will give values in either order and I'd actually be removing the ability to know which value is paired with which key. If I wanted the values themselves similar to the expected consensus output, I can do the path like $['key','another'][*] (the * token which I've yet to implement actually and am now reminded to do so).

from jsonpathkt.

Happy if some of the findings can improve the user experience of your implementation!

On the guaranteed order: Thanks for linking to the issue on the other side, I'm indeed not decided on that myself. The consensus at least makes it easy to keep my opinion out so far :) My best take right now is that a guaranteed order would make sense in cases where the user decides to elaborate on the query and say select the last match of the recursive decent, e.g. $.store..price[-1]. Obviously, if I don't guarantee ordering I also can't guarantee the result here.

To be overly nit-picky: apparently JSON does allow a key to come up multiple times (still valid!), so some standards (JWT for example) have explicitly called out that the last appearance of a key is respected where uniqueness is required. And it seems many JSON parsers seem to enforce that, with the result that ordering has an impact there.

Just to make my position clear, I do have personal opinions on what I expect for different queries, but those are just opinions of one user. As for the sake of the comparison project, I want to keep my own opinion out of that if I can. As for issue cburgmer/json-path-comparison#3 however, I do need to understand whether it has an effect on how the comparison is made, as it would constitute a new special case to be handled when diffing results.

A side from all that, feel free to close the bug if you have taken the feedback that's relevant for you. Let me know how you want to continue using that comparison, if it is helpful for you. This bug report was meant as an intro - happy to continue this as a service - but maybe the table over at the comparison is all you need for further improvements.

from jsonpathkt.

2.0.0 has been released and I've addressed all issues in this ticket, including the 2nd one I originally thought I wouldn't change. Closing

from jsonpathkt.