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
IP fields cause mapping conflicts #13112
Comments
@rjernst could you take a look please |
Actually, this isn't about default mappings, it is a problem with fields of type
|
@clintongormley Yes, it affects ip field type. The problem is how the search analyzer for ip fields is setup. For other numeric fields, it sets up an index analyzer for the numeric precision, and a search analyzer for the "max" value, and generally has constants for each possible precision. However, ip fields create these (even the "max" on for search analyzer) on the fly every time. This exposed a bug in our comparison of search analyzer when checking compatibility: we are looking at reference equality, instead of the name of the analyzer. When I found the bug, I realized we had a hole in the unit tests (it was something I was relying on existing mappings tests for, but that was obviously insufficient!). I have a fix ready, and have been working on an improved base test which will exhaustively test compatibility checks for every property, for every field type. |
The field type tests for mappings had a huge hole: check compatibility was not tested directly at all! I had meant for this to happen in a follow up after elastic#8871, and was relying on existing mapping tests. However, there were a number of issues. This change reworks the fieldtype tests to be able to check all settable properties on a field type work with checkCompatibility. It fixes a handful of small bugs in various field types. In particular, analyzer comparison was just wrong: it was comparing reference equality for search analyzer instead of the analyzer name. There was also no check for search quote analyzer. closes elastic#13112
While using the 2.0 branch, @jbudz and I are noticing that
_default_
mappings always cause unresolvable type conflicts.This is the mapping we are testing with:
And the documents that we are sending:
But the bulk fails with
"Mapper for [ip] conflicts with existing mapping in other types:\n[mapper [ip] is used by multiple types. Set update_all_types to true to update [search_analyzer] across all types.]"
.Since we are using
_default_
as the type, it seems likeupdate_all_types
should not be needed, since we are not actually creating the types until the documents are indexed.The text was updated successfully, but these errors were encountered: