<p dir="auto">We have some mapping options that sound interesting but are actually almost useless or dangerous. I propose to remove them:</p>
<h3 dir="auto"><code class="notranslate">_type: { index: no }</code></h3>
<p dir="auto">Not indexing the <code class="notranslate">_type</code> sounds appealing since documentation mentions everything will keep on working, so that should just save space. Except that elasticsearch will internally run a prefix query on the <code class="notranslate">_uid</code> field instead, which is going to be super slow. I think we should remove this option.</p>
<h3 dir="auto"><code class="notranslate">_type: { store: yes }</code> and <code class="notranslate">_id: { store: yes }</code></h3>
<p dir="auto">Storing the type and _id is useless since we already enforce the _uid to be stored, and the _uid contains these informations.</p>
<h3 dir="auto"><code class="notranslate">_id: { index: not_analyzed }</code></h3>
<p dir="auto">The <code class="notranslate">_id</code> field is the same for all documents so we should not need to index, store or doc-value it. (Can be done now thanks to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="32978899" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/6073" data-hovercard-type="pull_request" data-hovercard-url="/elastic/elasticsearch/pull/6073/hovercard" href="https://github.com/elastic/elasticsearch/pull/6073">#6073</a> and <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="44713017" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/7965" data-hovercard-type="pull_request" data-hovercard-url="/elastic/elasticsearch/pull/7965/hovercard" href="https://github.com/elastic/elasticsearch/pull/7965">#7965</a>)</p>
<p dir="auto">In general I'm wondering if we shouldn't go further and completely lock down how data is indexed/stored/docvalued for meta fields. There would just remain high-level configuration options such as <code class="notranslate">enabled</code> on the <code class="notranslate">_timestamp</code> mapper or <code class="notranslate">type</code> on <code class="notranslate">_parent</code>.</p>
<p dir="auto">Relates to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="51553271" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/8870" data-hovercard-type="issue" data-hovercard-url="/elastic/elasticsearch/issues/8870/hovercard" href="https://github.com/elastic/elasticsearch/issues/8870">#8870</a></p>
<p dir="auto">With <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="152001521" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/18075" data-hovercard-type="pull_request" data-hovercard-url="/elastic/elasticsearch/pull/18075/hovercard" href="https://github.com/elastic/elasticsearch/pull/18075">#18075</a> merged we now have the option to execute our doc snippets through the REST test infrastructure.</p>
<p dir="auto">Many of the small parts of original REST tests I've read look like great stories around how to use our REST API. I have no idea how much overlap there is between our docs and the REST test-suite, however I would imagine that one could convert several REST tests into nice pieces of documentation showing the complete story from indexing data to using the API under test.</p>
<p dir="auto">I'm wondering if it would make sense to consolidate what we are now (or in the hopefully near future) testing from within our docs and what is covered in the REST tests. (Intentionally not adding any version label to this issue - currently this is really just a vague question instead of a hard and fast proposal to move any specific way.)</p>