When a new node index.js new is executed the mapping for Elasticsearch is created from the file node-app/src/meta/elastic.js. All other fields, especially for the products, are created by Elasticsearch's dynamic field mapping functionality (https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-field-mapping.html). While this works in general some there are some attributes where it doesn't work.
So when the first product which references an attribute has an empty value or "0", which is a default for values stores in catalog_product_entity_int|decimal, is saved in ES, it is trying to "guess" the type for the mapping and assumes an "integer" field. When next product with has a value, lets say "37.5" is saved in ES, it throws an error like this:
response: '{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"failed to parse [configurable_children.width]"}],"type":"mapper_parsing_exception","reason":"failed to parse [configurable_children.width]","caused_by":{"type":"number_format_exception","reason":"For input string: \\"37.5\\""}},"status":400}',
Similar situations can happen for multiselects etc. So eelying on dynamic field mapping is not a stable solution as it only will work for some fields.
So a better approach would be to update the mapping from the attributes. From the attributes we can create the correct field mapping as we know which value to expect.
When a new
node index.js newis executed the mapping for Elasticsearch is created from the filenode-app/src/meta/elastic.js. All other fields, especially for the products, are created by Elasticsearch's dynamic field mapping functionality (https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-field-mapping.html). While this works in general some there are some attributes where it doesn't work.So when the first product which references an attribute has an empty value or "0", which is a default for values stores in catalog_product_entity_int|decimal, is saved in ES, it is trying to "guess" the type for the mapping and assumes an "integer" field. When next product with has a value, lets say "37.5" is saved in ES, it throws an error like this:
Similar situations can happen for multiselects etc. So eelying on dynamic field mapping is not a stable solution as it only will work for some fields.
So a better approach would be to update the mapping from the attributes. From the attributes we can create the correct field mapping as we know which value to expect.