Allow alias in "fields" in _mapping

[linker-c]

Description

It would be good to allow alias (or auto aliasing) if there are duplicate type attribute for a given field.

We often turn a "text" field into "keyword" because whole string matching is all we need.
A good example would be UUID or model (list of 5 possible models, etc)
There is really no reason to do a partial UUID search. It doesn't make sense (at least for our application).
So the most efficient way to define the mapping for this field would be "keyword".
This creates a potential issue for the caller with inconsistent query string. The caller needs to know if a field is a text or keyword natively.

Ex1:
Query string of "model" = "iPhone" vs "model.keyword" = "iPhone" is the difference here, depending on what "model" is defined as.

Ex2:

{
  "myindex" : {
    "mappings" : {
      "properties" : {
        "Username" : {. // searchable label
          "type" : "text",
          "fields" : {
            "keyword" : {. // incase the caller wants exact matching
              "type" : "keyword"
            }
         }
       },
        "Username_id" : {. // UUID record for this user
          "type" : "keyword",
          "fields" : {
            "keyword" : {
              "type" : "keyword"
            }
         }
       }
     }
   }
  }
}

From the above ex2, our practice has been add dot_keyword to "fields" for "Username_id" so the caller can have a consistent query pattern. Always use "label.keyword" for exact matching...

I just learned that this approach will cause 2 reverse index to be created for "Username_id" even though they are identical.

This feature request is to allow such duplicate "type" be specified via alias so we don't introduce unnecessary index for the convenience of standardizing namespaces.

[elasticsearchmachine]

Pinging @elastic/es-search (Team:Search)

[javanna]

heya @linker-c mappings already support field aliases, see https://www.elastic.co/guide/en/elasticsearch/reference/current/field-alias.html .

I believe if all you are looking for is two field names to point to the same inverted index, field aliases will be the solution.

[linker-c]

It doesn't work @javanna. I am not trying to point one field to another. I'm trying to point label.keyword to label itself.

PUT testing
{
  "mappings": {
    "properties": {
      "my_uuid": {
        "type": "keyword",
        "fields": {
          "keyword": {
            "type": "alias",
            "path":"my_uuid"
          }
        }
      }
    }
  }
}

{
  "error" : {
    "root_cause" : [
      {
        "type" : "mapper_parsing_exception",
        "reason" : "Type [alias] cannot be used in multi field"
      }
    ],
    "type" : "mapper_parsing_exception",
    "reason" : "Failed to parse mapping [_doc]: Type [alias] cannot be used in multi field",
    "caused_by" : {
      "type" : "mapper_parsing_exception",
      "reason" : "Type [alias] cannot be used in multi field"
    }
  },
  "status" : 400
}

[javanna]

Oh I see this interferes with the fact that they are in the same multi-field. You could do this through a runtime field. This is somehow related to #87969 . If field aliases were implemented as runtime fields internally, you would not have run into this problem. The workaround is to define a runtime field with a small script that loads the field that you want to alias.

[linker-c]

Thanks @javanna. Can you give me an example of how to do this with my simple example? If I understand you correctly, I'll need to create a new field which is kind of similar to your original suggestions.
My intend is to allow the API query to be agnostic about the "string" field.

[linker-c]

Can you please reopen this feature request since there's really no equivalent function to what I am looking for?
Thanks.

[javanna]

The equivalent functionality is a runtime field that extracts the value from the indexed field that you want to alias. Have you tried that?

#87969 will make this possible directly with an alias field.

[linker-c]

Thanks for the suggestion. I did a little bit research on runtime fields. it seems to equate to scripting.
Unfortunately, we don't allow scripting in our ES cluster. It's too difficult to debug and prone to catastrophic errors.
I understand the potential flexibility, but the risk is just too high.
Anyway, my suggestion/request is to eliminate the need to have duplicate reverse indices simply because of multi-fields. That's kind of a waste for no reason. Each "var" should simply keep one unique index type.