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

Join field type throwing "current_type [join], merged_type [ObjectMapper]" in 7.1.0 #43012

Closed
ffknob opened this issue Jun 8, 2019 · 4 comments
Labels
>bug :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch

Comments

@ffknob
Copy link

ffknob commented Jun 8, 2019

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:

  1. Create the index
PUT my-index
{
  "mappings": {
    "properties": {
      "text": {
        "type":  "text"
      },
      "join": {
        "type": "join",
        "relations": {
          "question": "answer"
        }
      } 
    }
  }
}
  1. Try to create a parent document:
POST my-index/1
{
  "text": "test",
  "join": {
    "name": "question"
  }
}

Result:

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "mapper [join] of different type, current_type [join], merged_type [ObjectMapper]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "mapper [join] of different type, current_type [join], merged_type [ObjectMapper]"
  },
  "status": 400
}

The same example (with doc as a type) work in 6.5.0.

Provide logs (if relevant):

@ffknob
Copy link
Author

ffknob commented Jun 9, 2019

I just got it to work by including the type _doc in the URL... Actually that's how the examples for the join datatype in 7.x are written, but I completely ignored it because I thought types were completely gone in 7.x...

POST my-index/_doc/1
{
  "text": "test",
  "join": "question"
}

Still a bug?

@jimczi
Copy link
Contributor

jimczi commented Jun 10, 2019

In 7.x POST my-index/1 means add a document in an index named my_index of type 1. This should result in an error with a message like:

"Rejecting mapping update to [my-index] as the final mapping would have more than 1 type: [_doc, 1]"

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 POST my-index/_doc/1.

@jimczi jimczi added :Search Foundations/Mapping Index mappings, including merging and defining field types >bug labels Jun 10, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

jtibshirani added a commit that referenced this issue Aug 12, 2019
…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.
@jtibshirani
Copy link
Contributor

I merged #45157 to address the confusing error message. Thanks @ffknob for filing this!

jtibshirani added a commit that referenced this issue Aug 12, 2019
…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.
jtibshirani added a commit that referenced this issue Aug 12, 2019
…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.
@javanna javanna added the Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch label Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch
Projects
None yet
Development

No branches or pull requests

5 participants