Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping update fails if _all.enabled was set to false - MergeMappingException #8423

Closed
mfussenegger opened this issue Nov 10, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@mfussenegger
Copy link
Contributor

commented Nov 10, 2014

In ES 1.4.0 it is no longer possible to update the mapping if _all.enabled has been set to false and _all isn't present in the updating request

create index t:

http put localhost:9200/t/

create mapping:

http put localhost:9200/t/_mapping/default default:='{"dynamic": "strict", "_all": {"enabled": false}}'

update mapping:

http put localhost:9200/t/_mapping/default default:='{"dynamic": "true"}

Fails with:

 "error": "MergeMappingException[Merge failed with failures {[mapper [_all] enabled is false now encountering true]}]", 

If I include _all in the request it works as expected:

http put localhost:9200/t/_mapping/default default:='{"dynamic": "true", "_all": {"enabled": false}}'
{
     "acknowledged": true
}

In 1.3.5 that was possible.

@clintongormley

This comment has been minimized.

Copy link
Member

commented Nov 10, 2014

@mfussenegger thanks for reporting. i've confirmed this.

Also, updating the _default_ mapping will remove the _all mapping:

DELETE _all 

PUT t

PUT /t/_mapping/_default_ 
{
  "dynamic": "strict",
  "_all": {
    "enabled": false
  }
}

Here, the _all mapping is present:

GET /_mapping

PUT /t/_mapping/_default_ 
{
  "dynamic": "true"
}

And now it is gone:

GET /_mapping

brwe added a commit to brwe/elasticsearch that referenced this issue Nov 10, 2014

[root mappers] fix conflict when updating mapping with _all disabled
_all reports a conflict since elastic#7377. However, it was not checked if _all
was actually configured in the updated mapping. Therefore whenever _all
was disabled a mapping could not be updated unless _all was again added to the
updated mapping.
Also, add enabled setting to mapping always whenever enabled was set explicitely.

closes elastic#8423
@brwe

This comment has been minimized.

Copy link
Contributor

commented Nov 10, 2014

This is a bug indeed, thanks for reporting. opened pr #8426

brwe added a commit that referenced this issue Nov 20, 2014

[root mappers] fix conflict when updating mapping with _all disabled
_all reports a conflict since #7377. However, it was not checked if _all
was actually configured in the updated mapping. Therefore whenever _all
was disabled a mapping could not be updated unless _all was again added to the
updated mapping.
Also, add enabled setting to mapping always whenever enabled was set explicitely.

closes #8423
closes #8426

@brwe brwe closed this in 4b5592c Nov 20, 2014

brwe added a commit that referenced this issue Nov 20, 2014

[root mappers] fix conflict when updating mapping with _all disabled
_all reports a conflict since #7377. However, it was not checked if _all
was actually configured in the updated mapping. Therefore whenever _all
was disabled a mapping could not be updated unless _all was again added to the
updated mapping.
Also, add enabled setting to mapping always whenever enabled was set explicitely.

closes #8423
closes #8426
@miccon

This comment has been minimized.

Copy link

commented Nov 24, 2014

There seems to be another issue with the _all field in combination with the _default_ mapping:

I recreated the issue here:
https://gist.github.com/miccon/a4869fe04f9010015861#file-strictallmappingtest-java

Failing on 21de386

@brwe

This comment has been minimized.

Copy link
Contributor

commented Nov 25, 2014

@pkoenig10 thanks a lot for the test, this is incredibly helpful. It seems to me the issue is not in _all mapper but rather that the type is created when indexing the document even though the indexing fails. I will open a separate issue shortly.

@miccon

This comment has been minimized.

Copy link

commented Nov 25, 2014

Thanks for the quick reply. Another thing I also noticed is that closing and reopening the index after the failed indexing makes the test pass. So it may be that the type gets somehow created but not persisted.

mute pushed a commit to mute/elasticsearch that referenced this issue Jul 29, 2015

[root mappers] fix conflict when updating mapping with _all disabled
_all reports a conflict since elastic#7377. However, it was not checked if _all
was actually configured in the updated mapping. Therefore whenever _all
was disabled a mapping could not be updated unless _all was again added to the
updated mapping.
Also, add enabled setting to mapping always whenever enabled was set explicitely.

closes elastic#8423
closes elastic#8426
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.