# What's the advantage of setting up index manually vs handled by client

**URL:** <https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006>\
**Category:** Elasticsearch\
**Created:** [July 28, 2017, 7:45pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006 "2017-07-28T19:45:13Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jessec](https://avatars.discourse-cdn.com/v4/letter/j/9d8465/32.png) [@Jessec](https://discuss.elastic.co/u/Jessec)\
**Post date:** [July 28, 2017, 7:45pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006/1 "2017-07-28T19:45:13Z")

</div>

If I use transport client for elasticsearch, when indexing a document to a non-existing index, it will automatically generate the new index and figure out the mapping from the first document. Please correct me if I got it wrong.

So my question is, do we still need to set up an index manually using XPUT? Is there any advantage of doing this?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [July 28, 2017, 8:44pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006/2 "2017-07-28T20:44:44Z")

</div>

Definitely better to control index settings and mappings.

That said an index template can do that for you anytime you index a new document in a non existing index.

---

<div class="post-metadata">

**Author:** ![Jessec](https://avatars.discourse-cdn.com/v4/letter/j/9d8465/32.png) [@Jessec](https://discuss.elastic.co/u/Jessec)\
**Post date:** [July 28, 2017, 9:05pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006/3 "2017-07-28T21:05:59Z")

</div>

But is it true that it's actually the mapping that really matters in terms of opting for manual setting? In other word, only putting an index doesn't help at all, since dynamic template can easily figure out the index name but mapping is more complicated. If the first document is malformed, then the mapping could be problematic.

And would it cause any problem when indexing a document that doesn't match the preset mapping? In the sense that control index setting and mapping is more reliable and prevent unmapping documents?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [July 28, 2017, 9:48pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006/4 "2017-07-28T21:48:59Z")

</div>

Index settings are also important IMO. You may be don't want to have 5 shards per index if 1 is enough.  
Also custom analyzers....

But yes mapping matters a lot.

Indexing a doc which has other fields than the ones defined in mapping will generate a mapping update by default.

---

<div class="post-metadata">

**Author:** ![Jessec](https://avatars.discourse-cdn.com/v4/letter/j/9d8465/32.png) [@Jessec](https://discuss.elastic.co/u/Jessec)\
**Post date:** [July 29, 2017, 3:54pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006/5 "2017-07-29T15:54:51Z")

</div>

[https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html#\_updating\_existing\_mappings](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html#_updating_existing_mappings)

But in the official documentation it says :

Other than where documented, existing type and field mappings cannot be updated. Changing the mapping would mean invalidating already indexed documents. Instead, you should create a new index with the correct mappings and reindex your data into that index.

So are you saying that if a document has more fields than the mapping, it would upgrading the mapping by adding the new fields? But the existing documents don't have such fields. Would it be a problem?

Also, how about a document has a field that doesn't match the type defined in the mapping? For instance, I have a field called "day" in mapping defined as a number , but I index a document with a field called "day" that is a string?

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [July 29, 2017, 4:10pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006/6 "2017-07-29T16:10:02Z")

</div>

> [@Jessec](#):
>
> So are you saying that if a document has more fields than the mapping, it would upgrading the mapping by adding the new fields? But the existing documents don’t have such fields. Would it be a problem?

As long as all fields that are defined have the same type, it does not matter is not all fields are present in all documents.

> [@Jessec](#):
>
> Also, how about a document has a field that doesn’t match the type defined in the mapping? For instance, I have a field called “day” in mapping defined as a number , but I index a document with a field called “day” that is a string?

This would result in a mapping conflict that would prevent the new document from being indexed.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [August 26, 2017, 4:10pm UTC](https://discuss.elastic.co/t/whats-the-advantage-of-setting-up-index-manually-vs-handled-by-client/95006/7 "2017-08-26T16:10:17Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
