Filters not working intuitively

[apatrida]

Maybe it is my misunderstanding, but with this data:

 {
            "a": {
                "b": [{
                    "c": {
                        "d": {
                            "e": "foo"
                        }
                    },
                    "something": "bar"
                }, {
                    "c": {
                        "d": {
                            "e": "miss"
                        }
                    }
                }]
            }
}

With the following query, nothing returns:

a.b[*].c.d[?e == 'foo']

But this does work:

a.b[*].c.d|@[?e == 'foo']

And in JSON Path (JayWay implementation for example):

a.b[*].c.d[?(@.e == "foo")] is the equivalent.

Is this intentional? they seem functionally equivalent but obviously are not. This fails in the playground (JavaScript), but also fails in the Java implementation.

Is this a spec issue? As designed? Common bug in all implementations? Where do we report something like this that seems to be prevalent across all of JMES?

(jmespath/jmespath.test#15)

[apatrida]

Another odd example, using contacts JSON below:

Fails:

contacts[?addresses[*].state == 'NY'].[firstName, lastName]

Succeeds:

contacts[?addresses[0].state == 'NY'].[firstName, lastName]

or

contacts[?addresses[?state == 'NY']].[firstName, lastName]

and the JSON Path (Jayway) equivalent is:

contacts[?(@.addresses[?(@.state == "NY")])]

So I guess it is the same as that, in that a projection cannot be used within a truthy expression?

INPUT JSON:

{
  "contacts": [
    {
      "firstName": "John",
      "lastName": "Smith",
      "isAlive": true,
      "age": 25,
      "addresses": [
        {
          "streetAddress": "21 2nd Street",
          "city": "New York",
          "state": "NY",
          "postalCode": "10021-3100"
        }
      ],
      "phoneNumbers": [
        {
          "type": "home",
          "number": "212 555-1234"
        },
        {
          "type": "office",
          "number": "646 555-4567"
        },
        {
          "type": "mobile",
          "number": "123 456-7890",
          "faceTime": true
        }
      ],
      "spouse": null
    },
    {
      "firstName": "David",
      "lastName": "Williams",
      "isAlive": true,
      "age": 34,
      "addresses": [
        {
          "streetAddress": "4545 W 51st",
          "city": "New York",
          "state": "NY",
          "postalCode": "10021"
        }
      ],
      "phoneNumbers": [
        {
          "type": "home",
          "number": "212 555-9919"
        },
        {
          "type": "mobile",
          "number": "212 555-1111",
          "faceTime": false
        }
      ]
    },
    {
      "firstName": "Bridget",
      "lastName": "Jamenson",
      "isAlive": true,
      "age": 23,
      "addresses": [
        {
          "streetAddress": "318 N. Rosemont",
          "city": "Dalles",
          "state": "TX",
          "postalCode": "75208"
        }
      ],
      "phoneNumbers": [
        {
          "type": "home",
          "number": "214 555-9913"
        },
        {
          "type": "mobile",
          "number": "214 555-3300",
          "faceTime": true
        },
        {
          "type": "office",
          "number": "214 555-0001"
        }
      ]
    }
  ]
}

[iconara]

When I test your expressions on jmespath.org I get the same results as with jmespath-java, so I think it's working as intended.

The first example I agree is confusing, and I think it has to do with the counter-intuitive way that projections work. You think that if you can do ….d.e you should be able to do ….d[?e == '...'], but in a projection it doesn't work like that. You need to terminate the projection (with a |) to get back into normal mode for that to work. In the projection the current node (@) does not refer to what you intuitively think it would.

In the second example addresses[*].state results in a list, and comparing that to a string will never succeed, it is not equivalent to your JSONPath example. contacts[?addresses[*].state == ['NY']] works, for some definition of works.

[apatrida]

Yes, I get the second one after I looked at it more. The first makes it hard because adding a | pipe means that traceability across the boundary is difficult to know what flows from one side to the other -- which is what I'm working on, I have tracing and pathing working, relative paths for updates, etc. but not in the case of crossing something that breaks traceability like pipes. I'll have to see if I can reconnect cross a pipe to objects that are selected at the first level that match the left side, and connect up the trace, and then continue. Otherwise, yeah.