-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Join field type throwing "current_type [join], merged_type [ObjectMapper]" in 7.1.0 #43012
Comments
I just got it to work by including the type
Still a bug? |
In 7.x
but it seems that we check the field first even though we know that the mapping update will fail (because only one type is allowed per index). This should be considered as a bug because the error message is misleading but as you already noticed the correct syntax is to use |
Pinging @elastic/es-search |
…ng. (#45157) Currently, when adding a new mapping, we attempt to parse + merge it before checking whether its top-level document type matches the existing type. So when a user attempts to introduce a new mapping type, we may give a confusing error message around merging instead of complaining that it's not possible to add more than one type ("Rejecting mapping update to [my-index] as the final mapping would have more than 1 type..."). This PR moves the type validation to the start of `MetaDataMappingService#applyRequest` so that we make sure the type matches before performing any mapper merging. We already partially addressed this issue in #29316, but the tests there focused on `MapperService` and did not catch this problem with end-to-end mapping updates. Addresses #43012.
…ng. (#45157) Currently, when adding a new mapping, we attempt to parse + merge it before checking whether its top-level document type matches the existing type. So when a user attempts to introduce a new mapping type, we may give a confusing error message around merging instead of complaining that it's not possible to add more than one type ("Rejecting mapping update to [my-index] as the final mapping would have more than 1 type..."). This PR moves the type validation to the start of `MetaDataMappingService#applyRequest` so that we make sure the type matches before performing any mapper merging. We already partially addressed this issue in #29316, but the tests there focused on `MapperService` and did not catch this problem with end-to-end mapping updates. Addresses #43012.
…ng. (#45157) Currently, when adding a new mapping, we attempt to parse + merge it before checking whether its top-level document type matches the existing type. So when a user attempts to introduce a new mapping type, we may give a confusing error message around merging instead of complaining that it's not possible to add more than one type ("Rejecting mapping update to [my-index] as the final mapping would have more than 1 type..."). This PR moves the type validation to the start of `MetaDataMappingService#applyRequest` so that we make sure the type matches before performing any mapper merging. We already partially addressed this issue in #29316, but the tests there focused on `MapperService` and did not catch this problem with end-to-end mapping updates. Addresses #43012.
Elasticsearch version:
7.1.0
Plugins installed: []
JVM version (
java -version
):openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-suse-lp150.7.1-x8664)
OpenJDK 64-Bit Server VM (build 10.0.2+13-suse-lp150.7.1-x8664, mixed mode)
OS version (
uname -a
if on a Unix-like system):Linux berlin 4.12.14-lp150.12.25-default #1 SMP Thu Nov 1 06:14:23 UTC 2018 (3fcf457) x86_64 x86_64 x86_64 GNU/Linux
Description of the problem including expected versus actual behavior:
I was trying to follow the examples provided by the documentation related to the
join
field type, but I could not reproduce them in 7.1.0. Although they work in 6.5.0.Steps to reproduce:
Result:
The same example (with
doc
as a type) work in 6.5.0.Provide logs (if relevant):
The text was updated successfully, but these errors were encountered: