Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
Original issue reported on code.google.com by
oliol...@gmail.com
on 19 Mar 2013 at 12:13