We all know that JSON syntax does not support comments, for good and bad reasons.
Also, we know that in many cases, comments are really, really useful, and that it's mostly up to the receiver to not do anything bad with them, like using them for processing instructions or so.
Can ElasticSearch be made lenient at least with respect to e.g. "_comment":"<value>" pairs in its RESTful API? On recption, ElasticSearch would just ignore any and all of these pairs, including their value. On JSON production, such pairs would never be produced, as today.
This well-known pattern is compatible with strict JSON syntax and does not have any functional impact. It furthers, on the other hand, support for transparency and traceability which are important aspects or even prerequisites for some processes, for many organizations.
This roughly duplicates #30576. We discussed it as a team and concluded at that time that we wouldn't do this, reasoning that:
the query language is a communication protocol between client and server and not a user interface.
_comment fields in documents would be a breaking change to users that currently index
_comment fields. We try not to make breaking changes without a very good reason. We also don't really like lenience as a general rule, because it makes it all too easy to quietly do the wrong thing.
X-Opaque-Id header is a good way to add traceability to your Elasticsearch usage.
Thanks for your speedy reply and for mentioning the earlier issue that unfortunately I had failed to see.
X-Opaque-Id is a great idea (available since 6.2 as per the docs). I shall look into that for communication-level transparency.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.