freestrings / jsonpath

JsonPath engine written in Rust. Webassembly and Javascript support too
MIT License
122 stars 37 forks source link

Dot notation path containing a colon character fails to match #75

Open oshadmi opened 3 years ago

oshadmi commented 3 years ago

The following test fails due to the $.prod:id path

#[test]
fn colon_token_in_path() {
    setup();

    let payload = json!({
        "prod:id": "G637",
        "prod_name": "coffee table",
        "price": 194
    });

    select_and_then_compare("$.price", payload.clone(), json!([194]));

    select_and_then_compare("$.prod_name", payload.clone(), json!(["coffee table"]));

    select_and_then_compare("$.prod:id", payload.clone(), json!(["G637"]));
}

Returning an empty array []

test colon_token_in_path ... FAILED

failures:

---- colon_token_in_path stdout ----
thread 'colon_token_in_path' panicked at 'assertion failed: `(left == right)`
  left: `[]`,
 right: `[String("G637")]`: $.prod:id', tests/common.rs:41:5
oshadmi commented 3 years ago

Using the bracket notation is working well select_and_then_compare("$[\"prod:id\"]", payload.clone(), json!(["G637"]));

cburgmer commented 3 years ago

Reading the draft specification I would say we might be converging on an interpretation of JSONPath where the colon : should not be considered a valid char in the dot notation: https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/blob/main/draft-ietf-jsonpath-base.md#dot-selector.

freestrings commented 3 years ago

@oshadmi I agree with the "ietf-wg-jsonpath" specification. What do you think?

oshadmi commented 3 years ago

@freestrings For the current spec/implementation, we prefer to support the colon : as a valid character in the dot notation, since it is widely used with redis. I can try to contribute a fix for this. What do you think?

freestrings commented 3 years ago

I haven't thought about how to implement it, but how about an approach of turning additional features on and off with a setting?