Different null_value for different doc type of same index


(gchen) #1

Hi

Is it possible to set the null_value to different values for different doc type of same index?

I'm able to do it for version 1.4. I'm working on upgrading our cluster to 2.4 now and its erroring out.

{
  "text "status": 400,
   "error": {
    "caused_by": {
      "reason": "Mapper for [product] conflicts with existing mapping in other types:\n[mapper [product] is used by multiple types. Set update_all_types to true to update [null_value] across all types.]",
      "type": "illegal_argument_exception"
    },
    "reason": "Failed to parse mapping [my_doc_type]: Mapper for [product] conflicts with existing mapping in other types:\n[mapper [product] is used by multiple types. Set update_all_types to true to update [null_value] across all types.]",
    "type": "mapper_parsing_exception",
    "root_cause": [
      {
        "reason": "Failed to parse mapping [my_doc_type]: Mapper for [product] conflicts with existing mapping in other types:\n[mapper [product] is used by multiple types. Set update_all_types to true to update [null_value] across all types.]",
        "type": "mapper_parsing_exception"
      }
    ]
  }
}

I want to have something like...

{
 "mappings": {
       "type_one": {
            "properties": {
                "product": {
                    "type": "string",
                    "null_value": "type_one_value"
                }
            }
        },
       "type_two": {
            "properties": {
                "product": {
                    "type": "string",
                    "null_value": "type_two_value"
                }
            }
        }
}

(Tal Levy) #2

Not that I am aware [1].

Since types are going away in 6.0 anyways, I would maybe re-think how you are organizing your documents in such a way that this is not a problem. _type is just another field. If performance for the affected queries is not of too much concern, you may want to take a look at scripted fields


(gchen) #3

Thanks for the comment. Most likely that's what i'm going to do. But we have a considerable size cluster, about 40TB, so the number of indices that we have to create will be significant.


(Tal Levy) #4

one other solution would be to run these index requests with an ingest-pipeline that sets fields when they are null to specific values you wish


(system) #5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.