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

Enhanced support for filtering #29

Closed
GoogleCodeExporter opened this issue Sep 22, 2015 · 7 comments
Closed

Enhanced support for filtering #29

GoogleCodeExporter opened this issue Sep 22, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. You have the following json:
{"list":
  [
    {
      "a":"atext,
      "b":{
         "b-a":"batext,
         "b-b":"bbtext"
       }
    },
    {
      "a":"atext2,
      "b":{
         "b-a":"batext2,
         "b-b":"bbtext2"
       }
    }
  ]
}
2. you have a json path like: $.list[?(@.b.b-a=='batext2')]
3. or a filter like: JsonPath.read(result, "$.list[?]", 
Filter.filter(Criteria.where("b.b-a").eq("batext2")));

What is the expected output? What do you see instead?
Actual: Empty list

Expected: a matching jsong object



What version of the product are you using? On what operating system?
0.8.1

Please provide any additional information below.

Original issue reported on code.google.com by oliol...@gmail.com on 19 Mar 2013 at 12:13

@GoogleCodeExporter
Copy link
Author

3. should work with the recent changes on github.
2. doesn't as JsonPath would try to read a property named "b.b-a" of the list 
object.

There are several options where we could go from here:
* Leave it as it is, you can always use the varargs method
* Always interpret dots as "path separators", however that doesn't seem to be 
what the JayWay guys want, though I'd say that dots in property names are the 
exception rather than the usual case.
* Introduce a special syntax to differentiate between a dot as path separator 
or as part of a property name (like . vs. \.)
* Add an additional parameter to JsonPath.compile that specifies how to 
interpret dots. That would have to be passed through to PathToken, 
FilterFactory and eventually to the Filter implementations.
* Differentiate between dot and array notation, that is, treat @.b.b-a as a 
this->b->b.a and @['b.b-a'] as this->b.b-a

None of the possibilities convince me entirely but after giving it some 
thought, I think I like the last one best.

Original comment by foober...@gmail.com on 22 May 2013 at 9:22

@GoogleCodeExporter
Copy link
Author

Great, I will check the filter.

So if I use an array notation, the dots will be handled as path separators if 
the parameter is not between '-s. So it means we cannot mix the two things like:
@[b.'a.b'.c]
what if we say you have to put those property names between '-s what has a 
dot...
or make a hidden check can it return with a property named: 'b.b-a' if not, it 
tries to read it as a path... (you still cannot mix things here as well)

but to be honest, using dots in property names is just not fair :)

Original comment by oliol...@gmail.com on 22 May 2013 at 11:17

@GoogleCodeExporter
Copy link
Author

You could write @.b.['a.b'].c in that case. Of course, we'd get a problem if 
the property name also contains an apostrophe, but I guess that's a little 
far-fetched.
I thought about what you call a "hidden check" too, but I think, it's not quite 
intuitive. It would cause both {"b.b-a": "foo"} and {"b": {"b-a": "foo}} to be 
matched and you wouldn't have a way to match either one exclusively.

Original comment by foober...@gmail.com on 22 May 2013 at 11:39

@GoogleCodeExporter
Copy link
Author

hm.. I still cannot get it, let's put it back to the original context:
we have these two json paths?:
$.list[?(@.b.b-a=='batext2')] --> match 2nd object in array 
$.list[?(@.['b.b-a']=='batext2')] --> match 1st object in array

so the new json is:
{"list":
  [
    {
      "a":"atext",
      "b.b-a":"batext2"
      "b":{
         "b-a":"batext",
         "b-b":"bbtext"
       }
    },
    {
      "a":"atext2",
      "b":{
         "b-a":"batext2",
         "b-b":"bbtext2"
       }
    }
  ]
}

Hopefully no one uses apostrophes in names...

that's true with the hidden check, that's why I thought to use a name match 
first, because that was the previous behavior and do the other if it cannot 
find something. But it is dirty anyway.


Original comment by oliol...@gmail.com on 22 May 2013 at 12:32

@GoogleCodeExporter
Copy link
Author

Oh, sorry, I got it wrong in my last comment. If we went that way, it would be 
*either* dots *or* array notation, so it would be @.b['a.b']c and not 
@.b.['a.b'].c.

Your second expression would have to read $.list[?(@['b.b-a']=='batext2')] then

Apart from that, I'd expect the same matches.

Original comment by foober...@gmail.com on 22 May 2013 at 12:56

@GoogleCodeExporter
Copy link
Author

ah, ok. so if your property name has a dot you have to use bracket notation.

sounds really good 

Original comment by oliol...@gmail.com on 22 May 2013 at 1:19

@GoogleCodeExporter
Copy link
Author

This is supported in 0.9.0, soon to be released.

Original comment by kalle.st...@gmail.com on 22 Aug 2013 at 8:36

  • Changed state: Fixed

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

1 participant