'Elasticsearch 6: Rejecting mapping update as the final mapping would have more than 1 type

I'm trying to convert a project to use the latest Elasticsearch 6 and am having this problem. I don't know if the problem is "Product" vs "product". In my mappings and attributes I specify "products", so I am not sure why I get this error when I try to index a product.

Error:

Invalid NEST response built from a unsuccessful low level call on PUT: /products/products/1?pretty=true&error_trace=true

"Rejecting mapping update to [products] as the final mapping would have more than 1 type: [Product, products]"

Request:

{
  "id": 1,
  "warehouseId": 0,
  "productStatus": 1,
  "sku": "102377",
  "name": "Name",
  "shortDescription": "Description",
  "longDescription": "Description",
  "price": 37.3200
}

My code:

    [ElasticsearchType(Name = "products")]
    public class Product : BaseEntity
    {
        [Key]
        public int Id { get; set; }
        public int WarehouseId { get; set; }
        [Display(Name = "Product Status")]
        public Enums.ProductStatus ProductStatus { get; set; }
        [Required, StringLength(10)]
        public string Sku { get; set; }
        [Required, StringLength(200)]
        public string Name { get; set; }
        [StringLength(500), Display(Name = "Short Description")]
        public string ShortDescription { get; set; }
        [DataType(DataType.MultilineText), Display(Name = "Long Description")]
        public string LongDescription { get; set; }
        [Column(TypeName ="Money")]            
        public Nullable<decimal> Price { get; set; }
    }

connection.DefaultMappingFor<Product>(m => m.IndexName("products"));


Solution 1:[1]

This is because of a breaking change in ES 6.x: mapping types were removed (even if for backward compatibility you can still specify it in the path) thus de facto limiting the index to a single type.

See here for more info.

Solution 2:[2]

Prior to elasticsearch v6, an index can have only 1 mapping by default. In previous version 5.x, multiple mapping was possible for an index. Though you may change this default setting by updating index setting "index.mapping.single_type": false .

In your case, my assumption is you had already created the index with mapping Product. That is why it was rejecting new mapping in your second request with "product" (p in small case).

Solution 3:[3]

I deleted the index and recreated it and it appears to be fine now. I think when I first created the index I didn't have the correct attribute name so that might explain the error I was getting.

Solution 4:[4]

In my case I was trying to delete a record following the official docs and I blindly put the _doc in the URL which led to this error.

This should be the mapping that you see under the Indices tab against Mappings section in the AWS console. changing the value in the URL solved it for me.

Hope this was helpful :)

Solution 5:[5]

As Batsu says, from version 5 of elasticSearch onwards, the concept of treating the index as the database and the type as a table was removed to implement a lucene optimization.

The solution is to use an index by @Document.

Referral: https://www.elastic.co/guide/en/elasticsearch/reference/6.7/removal-of-types.html

Solution 6:[6]

My problem was in ES 6.8 for which I was using the PHP ElasticSearch client to send requests. My index was already using a single type but the type name was not the default _doc that was suggested/expected. In addition I was not adding the "type" parameter in the request to specify what the type was. My code:

$this->client->delete([
   "index" => 'myIndexName',
   "id" => $idToDelete
])

This resulted in the client adding a default type which was _doc which in my case was incorrect. Adding an explicit type in the request fixed the issue like below:

$this->client->delete([
   "index" => 'myIndexName',
   'type' => 'myTypeName',
   "id" => $idToDelete
])

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 Prabuddha Chakraborty
Solution 3 Primico
Solution 4 Karan Sharma
Solution 5 Manuel Larrota
Solution 6 apokryfos