json4s
json4s copied to clipboard
json4s
strange behavior of filterField
Contents of the nested JObject spill over into top level as a result of filtering. An illustration: https://gist.github.com/divijan/79d96b8fdc1848a66a36
I just tried to reproduce your issue here:
https://github.com/json4s/json4s/blob/bfaffc23ff2019463101ec41edbcc1f900bc78e7/tests/src/test/scala/org/json4s/Examples.scala#L160-L183
But the example works on my machine and on Travis.
https://travis-ci.org/json4s/json4s/builds/77872948
You must have missed the "strange" part. Try adding
filtered1.exists(_._1 == "description") must_== false
filtered1.exists(_._1 == "code") must_== false
and
filtered2.exists(_._1 == "description") must_== false
filtered2.exists(_._1 == "code") must_== false
into your test. These should remain nested and shouldn't show up on the top level. Note that I am using json4s-jackson 3.2.11
Thanks. Acutally I agree this behavior doesn't look intuitive.
Return a List of all fields which matches the given predicate. https://github.com/json4s/json4s/blob/3.3/core/src/main/scala/org/json4s/MonadicJValue.scala
Basically methods defined on the MonadicJValue tends to scan all the fields recursively. I'm not sure we should change this behavior now.
@olkinn It is better to avoid changing existing behavior from the viewpoint of backward compatibility, but if there are many requests, I think that it is possible to add a filter method that targets only the top level.
But if you are only targeting the top level, isn't the code so difficult and you don't have to provide it as a library? Also think.
In any case, I think scaladoc needs to be added recursively.
I got bitten by this. I see using a widely conventional name like map to do something unconventional like recursively mapping as a bug. I would not be surprised if other users of json4s have silent bugs as a result of expecting conventions to be followed.
