Json support in painless #60925
Json support in painless #60925
Conversation
|
|
||
| // pretty print | ||
| output = exec("Json.dump(params.data, true)", singletonMap("data", singletonMap("hello", "world")), true); | ||
| assertEquals("{\n \"hello\" : \"world\"\n}", output); |
There was a problem hiding this comment.
Can you include a test with multiple keys on the same level to ensure that deterministic order (sorting) is done?
{
"key_a": "keys must be sorted",
"key_b": 10,
"key_c": 1
}
There was a problem hiding this comment.
@ypid-geberit thanks for the comment.
This change exposes internal elasticsearch json utility functions. Determinisitic ordering of output is not a requirement for this change.
There was a problem hiding this comment.
If you'd like to request a feature, please submit an issue so we can discuss and prioritize it.
There was a problem hiding this comment.
This requirement together with reasoning is part of #37585 that this PR intends to implement. So in this PR it should be stated if you see this as in scope of this PR or not.
Your comment suggests that you don’t. I see this as bad design. It will break your unit tests in hard to debug ways in the future. Not to mention that I could not use this new feature at all for my watch testing and would need to stick with workarounds as shown in #37585.
There was a problem hiding this comment.
I'm not opposed to it, but it's not a requirement for this PR. It can be added here or in a later PR.
There was a problem hiding this comment.
Let's take the ordering over in a new PR after we get this one in. There's going to be a lot of SPI work here already.
We want two modes:
- Preserve ordering.
dumps(loads(String))should be as close to a no-op as possible. - Force ordering. Probably need to add an additional flag.
Thanks.
There was a problem hiding this comment.
Json maps are, by design, unordered. Thus adding support for json serialization/deserialization to painless should be unencumbered by a requirement to support it, which is what this PR is about. Tests can be made robust to this, just as tests exist for maps in java which do not guarantee iteration order.
Preserve ordering. dumps(loads(String)) should be as close to a no-op as possible.
I don't think this should be a requirement. That would mean the default is to preserve order, which is (1) outside the requirements of json and (2) brings the cost of a heavier weight data structure (eg linked hash map or tree map). Most users of json do not care about the order, since it is not guaranteed by any tools by default.
There was a problem hiding this comment.
Tests can be made robust to this, just as tests exist for maps in java which do not guarantee iteration order.
That is a view that I can understand. Note that currently, it is not supported for testing watches this way however. If this issue next steps on my toes, I will consider changing the testing design to something where Watches would output valid JSON, and then compare the actual output with the expected output in Python. I will add it to elastic/examples#239 (in case anyone cares 😉).
However, I am still very interested in a sort_keys (ref: https://docs.python.org/3/library/json.html#json.dump) feature. Feel free to ignore this requirement in this PR as discussed above.
Preserve ordering. dumps(loads(String)) should be as close to a no-op as possible.
I don't think this should be a requirement.
Agreed.
pgomulka
added
the
:Core/Infra/Scripting
|
Pinging @elastic/es-core-infra (:Core/Infra/Scripting) |
|
Json support in watcher added in 7.10 in #63278 |
This PR adds a
Jsonclass to the painless shared API forjson(de)serialization.