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

Remove the ability to delete mappings #8877

Closed
clintongormley opened this issue Dec 10, 2014 · 2 comments · Fixed by #10231
Closed

Remove the ability to delete mappings #8877

clintongormley opened this issue Dec 10, 2014 · 2 comments · Fixed by #10231
Assignees
Labels
>breaking :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v2.0.0-beta1

Comments

@clintongormley
Copy link
Contributor

Currently, a user can delete a type entirely, which deletes the type, all documents of that type, and removes the associated fields. Unfortunately, if any documents of that type have already been indexed, then the fields are part of the index. Adding fields with the same name but a different data type will cause conflicts later on. (See #8530 (comment))

We should remove the ability to delete types/mappings.

Relates to #8870

@clintongormley clintongormley added :Search Foundations/Mapping Index mappings, including merging and defining field types >breaking v2.0.0-beta1 help wanted adoptme labels Dec 10, 2014
@rjernst rjernst removed the help wanted adoptme label Mar 24, 2015
@rjernst rjernst self-assigned this Mar 24, 2015
rjernst added a commit to rjernst/elasticsearch that referenced this issue Mar 24, 2015
Deleting a type from an index is inherently dangerous because
the type can be recreated with new mappings which may conflict
with existing segments still using the old mappings. This
removes the ability to delete a type (similar to how deleting
fields within a type is not allowed, for the same reason).

closes elastic#8877
closes elastic#10231
rjernst added a commit to rjernst/elasticsearch that referenced this issue Mar 25, 2015
In elastic#8877, the deletion of the type associated with a river was
removed. This change adds back the removal using a scan search
along with bulk delete requests.
rjernst added a commit to rjernst/elasticsearch that referenced this issue Apr 19, 2015
This is mostly removing code that handled deletion of types, which was
removed in elastic#8877.
rjernst added a commit to rjernst/elasticsearch that referenced this issue Apr 20, 2015
This is mostly removing code that handled deletion of types, which was
removed in elastic#8877.

closes elastic#10666
rjernst added a commit to rjernst/elasticsearch that referenced this issue Apr 20, 2015
This is mostly removing code that handled deletion of types, which was
removed in elastic#8877.

closes elastic#10666
rjernst added a commit to rjernst/elasticsearch that referenced this issue Apr 20, 2015
This is mostly removing code that handled deletion of types, which was
removed in elastic#8877.

closes elastic#10666
@jasisz
Copy link

jasisz commented Aug 19, 2015

Just digged to that PR from the annoucment about removing delete by query and delete mapping in Elasticsearch 2.0. As far as I understand the problem is that the field name is stored directly in index and it is not possible to use it later with different type settings.

So how it will behave if in one index I have two types with mappings that have different types for the field named e.g. height in both? It would also give the same errors?

@clintongormley
Copy link
Contributor Author

@jasisz in 2.0 we explicitly forbid creating fields of the same name with conflicting mappings, for the same reason

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v2.0.0-beta1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants