[Feature request] Support for multi-fields

[ciaran51]

Scenario

Right now you can only index 1 field into 1 OpenSearch field. I'd like to be able to index the same field into two separate OpenSearch fields for use within ElasticGraph. This unlocks the ability to create keywords for precise search as well as text fields for partial searching.

t.field "customerName", "String" do |f|
  f.mapping type: "keyword"
  f.additional_mapped_field "customerNameText", type: "text" #new code
end

Possible solution

Example of what this could look like within the schema:

t.field "customerName", "String" do |f|
  f.mapping type: "keyword"
  f.additional_mapped_field "customerNameText", type: "text" #new code
end

In this case customerName and customerNameText both get indexed as their own fields within OpenSearch that you can perform all relevant ElasticGraph operations to that type on.

Open questions

• Can this be added without a re-index? Assume not

[myronmarston]

For reference, here are the docs on the datastore feature this would leverage:

• https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/multi-fields
• https://docs.opensearch.org/latest/mappings/mapping-parameters/fields/

Can this be added without a re-index? Assume not

I have not tried the multi-fields feature of either datastore, but the impression I have is that it doesn't require a re-index when adding an additional mapped field to an existing field. I think it acts the same as adding any other new field to an existing index: existing documents won't have a value for it (and so, searching on it won't be accurate until you've re-indexed) but it otherwise works fine.

In reading the docs, it looks like the additional mapped fields are defined as "child" fields with a dot separator, meaning that for the example above we'd wind up with two fields:

• customerName
• customerName.customerNameText

With that in mind, I think we'd actually want to use this feature like so:

t.field "customerName", "String" do |f|
  f.mapping type: "keyword"
  f.additional_mapped_field "text", type: "text" #new code
end

...which would instead add an extra field named customerName.text.

There are also some interesting questions to consider relating to how this would impact the GraphQL API we expose. There are a number of nuances/tradeoffs there.

Before moving forward with this, I'd love to see a full proposal written up (as a discussion) about how this would work end-to-end, particularly related to how it would work at the GraphQL layer.