How to define multiple index types mapping in single template

Hello Guyz,

I have default Template file of blueliv which was working on elasticsearch-6.2.3. but in 6.2.4 that mapping is not works.

I'm getting following error when i tried following configuration:

{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"No handler for type [string] declared on field [@version]"}],"type":"mapper_parsing_exception","reason":"Failed to parse mapping [_default_]: No handler for type [string] declared on field [@version]","caused_by":{"type":"mapper_parsing_exception","reason":"No handler for type [string] declared on field [@version]"}},"status":400

Could anyone help me to define new mappings which is compatible with elasticsearch-6.2.4.

Regards,
Yash M.

Use text instead of string.

Hello @dadoonet,

I changed the @version mapping to text but it seems like there is too many changes in 6.2.4. now after changing mapping string to text.

i'm getting following error.

{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"Failed to parse mapping [_default_]: Could not convert [@version.index] to boolean"}],"type":"mapper_parsing_exception","reason":"Failed to parse mapping [_default_]: Could not convert [@version.index] to boolean","caused_by":{"type":"illegal_argument_exception","reason":"Could not convert [@version.index] to boolean","caused_by":{"type":"illegal_argument_exception","reason":"Failed to parse value [not_analyzed] as only [true] or [false] are allowed."}}},"status":400}

I doubt you are seeing such a difference between 6.2.3 and 6.2.4.

I believe that the template was there in 6.2.3 (like upgraded from a previous version) but you are trying to upgrade the template using a removed format.

What gives for now:

GET _template/YOUR_TEMPLATE_NAME 

Not exactly, I'm trying to made working the same template to 6.2.4 version. All this testing i'm doing in fresh instance of new VM.

In my last error, as i suspected "_all" & index: 'not_analyzed' mapping is deprecated in 6.2.4.
so i removed both the settings from my template file. but now i'm facing such weird issue.

{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"Rejecting mapping update to [YeGfDJjeThiDFGQ1Qv6yDw] as the final mapping would have more than 1 type: [blueliv-malwares, blueliv-attacks]"}],"type":"illegal_argument_exception","reason":"Rejecting mapping update to [YeGfDJjeThiDFGQ1Qv6yDw] as the final mapping would have more than 1 type: [blueliv-malwares, blueliv-attacks]"},"status":400}

But you wrote:

I have default Template file of blueliv which was working on elasticsearch-6.2.3. but in 6.2.4 that mapping is not works.

I doubt about this.

I mean that I doubt the same template works on 6.2.3 and not on 6.2.4.

ie. You can't not create a new index with multiple types from 6.0.
Here the error message is about that.

Hello @dadoonet,

I understand what error message is all about. it's rejecting my multiple type settings in same index. but I have doubt because conceptually,

if we talk about normal database we can create as many tables as we want in a single database but in elasticsearch index acts like database and type is act like a table. if i consider conceptually. So, i can create as many type as we want.

If this is not the case then this update is conceptually wrong. then i want to know
what concept is actually followed by elastic ? I am assuming elastic may be have other alternative to acheive multiple types in same index. but i don't know the exact mapping to do that.

So i want to know if there is other alternative is in place to acheive this concept ?

It's another question than the original thread. But read this https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html

That analogy has not really been valid for quite a long time, as Elasticsearch has been enforcing consistent mappings for fields within an index for a long time now. Even though you could have multiple types in an index in Elasticsearch 5.x , if you had the same field used in these different types they still needed to have the same mapping.

If you necessarily want to use database analogies (I would recommend against it as it is a fundamentally different type of system), I think an Elasticsearch index is probably more like a table than a database due to these mapping constraints.

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