Newtonsoft.Json
Newtonsoft.Json copied to clipboard
JSONPath scripts not executing correctly for objects
Using scripts to query objects does not seem to work properly (although it does work properly for arrays). Given an example JSON:
{
"A": {
},
"B": {
"B1": 1,
"B2": 2
},
"C": {
"C1": {
"C11": true
},
"C2": 2
}
}
Parsing this into a JObject and then executing SelectTokens with a script does not yield the correct results
Running $[?(@)] from the root returns the all of the properties in the object, as expected
Running $[?(@.B1)] or $[?(@.B1 == 1)] should return the B property, but does not actually
If I use the recursive operator, $[?(@..B1)] then the B node is returned, which makes me think that the child operator is not working for a script inside an object.
Additionally, the value of the properties cannot be accessed from within the script.
If I run $[?(@ == 1)] inside the B object, I'd like to be returned the B1 token (or the token for its value) but it actually returns nothing.
The behavior that I'm referring to is based on the interpretation of the JSONPath spec expressions as well as the behavior of some JSONPath evaluators such as this and this) The examples that I mentioned above using JSON.Net can he found here.
I'm not sure about this. Nothing in the JSONPath says that filters should apply to objects.
The spec says that "expressions of the underlying script language can be used as an alternative to explicit names or indices", which makes me think that filter expressions can also be used instead of names.
I'm having the same problem as davilimap. I must admit I'm pretty new with JSONPath, so I don't know exactly if it's written in JSONPath specs but since applying filters on objects is working with JSONPath validators like jsonpath.com, I expected it to work with JSON.Net as well. Thanks for your impressive work.
I am facing the exact same issue. A quick test with Manatee.Json shows that its implementation of JsonPath yields the expected result. Stefan Goessner wrote : "With JSONPath square brackets operate on the object or array addressed by the previous path fragment."
That's a real bummer. Just ran into this issue myself and was surprised to see it's been left with no attention for almost three years now :(
Interested in this too.
Also interested in this.
Still interesting in this. Was a let down to see I couldn't do this and I'm now contemplating switching JSON libraries
any progress???
Also interested in this. Unfortunately, we'll likely have to switch to another JSON library that supports it.
Note that given the following JSON: {"x":{"a":1, "b":2}} and the given JSONPath expression: $.x.* - the result is [1, 2] - not [{"a":1}, {"b":2}] as some may expect. That's how JSONPath works. A match which is a map member resolves to the member's value.
Similarly, for the JSONPath expression, $.x[?@] the result is [1, 2] - just the values of members of x, and not [{"a":1}, {"b":2}]. Therefore you are not able to access @.a.
Similarly, for the JSONPath expression $[?@] - the result is [{"a":1, "b":2}] - just the value of x, and not ["x":{"a":1, "b":2}]