That won't work, we might be able to parse it with comments (thanks to jackson, its not a valid json), but, the way elasticsearch works is that it parses the mappings into its own structure, and then serialize it based on it back to the json string representation (thus causing comments to be lost...).

or probably skip lines beginning with # before parsing?

@karussell the problem is not with parsing, as that can be handled, its with how elasticsearch handles mapping. The json provided gets parsed into elasticsearch own mapping model, and then serialized back into the json (to form a consistent form of the mapping json, and only output whats applicable). There is no handling for comments in the mapping data structures so they can be serialized back.

@kimchy : I don't need to get comments back from ES. It's okay to loose it.
I just need to be able to manage my mapping definition files in my VCS and I would like to share comments with other developpers.

I see, I can enable comments in json parsing, just want to check the parsing overhead costs...

Nice. I can understand that you can not allow comments only for _mapping endpoint, so it can have side effects on other endpoints.
So, if there is any cost, as it's only a request feature for "confort" and it's not standard JSON, we can forget it !!!

I have similar issue with a really long mapping JSON file and without comments it is evil to manage. Having them stripped on return is no problem, it is the source material that requires them, not echo'ing or retrieval of the result

+1 for enabling comments. I am also ok with not getting them back from the _mapping endpoint.

Same here. My mapping file is heavily commented so that I remember why certain fields are configured the way they are. Also no need to have the comments preserved in the ES internal representation as I assume most people would have the original mapping stored in a VCS.

For testing purposes, I use the following (using Jackson) to strip out comments from my config and apply it to ES

JsonFactory jf = new JsonFactory();
jf.enable(JsonParser.Feature.ALLOW_COMMENTS);
ObjectMapper om = new ObjectMapper(jf);
JsonNode root = om.readTree("{/*Some comment*/\"field\":\"value\"}");
String noComments = om.writeValueAsString(root);
assertEquals("{\"field\":\"value\"}", noComments);

Which gives me an idea, if enabling JsonParser.Feature.ALLOW_COMMENTS globally could incur a penalty overhead, why not enable it for mappings only? I would imagine mappings don't get changed often, and it seems that comments are most useful precisely in that scenario.

Putting in my +1. Mappings get lengthy and complicated pretty quickly (and often involve a lot of little compromises whose rationalizations are quickly lost to time). It would be very helpful to be able to annotate them inline.

+1 - It'd be really helpful to be able to annotate my mapping files inline.

Found an interesting article discussing comments in JSON. It might be useful to keep the link here.
http://bolinfest.com/essays/json.html

+1

@kkrauth your suggestion worked for me for multi-line and single-line comments.

String unparsed1 = "/*this\n is\n a\n multi-line\n comment*/ {\"foo\": 1 /*another comment*/}";
String unparsed2 = "// single-line comment\n{\n  \"name\": \"1\"\t\t\n}";
JsonFactory jsonFactory = new JsonFactory();
jsonFactory.enable(JsonParser.Feature.ALLOW_COMMENTS);
ObjectMapper mapper = new ObjectMapper(jsonFactory);

// converting the json strings into JsonNodes
JsonNode parsed1 = mapper.readTree(unparsed2);
parsed1.get("foo"); // will contain 1

JsonNode parsed2 = mapper.readTree(unparsed2);
parsed2.get("name"); // will contain "1"

Sorry for the shoddy example; on a tight timeline at work but I hope this helps someone.

haha