[FEATURE] Allow to customize mappings parameters

[reta]

Background

The request is coming from the Spring Data OpenSearch where we tried to add vector field type support. The previously introduced mappedTypeName allows to resolve mismatch between dense_vector type (Elasticsearch) and knn_vector (OpenSearch). However, the further troubles are coming from pretty much non-compatible parameters (dims vs dimensions, similarity vs space_type, ...).

Suggested Changes

The Spring Data Elasticsearch should not be concerned with any OpenSearch specific differences, however since Spring Data OpenSearch is built on top, it has all the means to seal these differences, without any user visible changes. The key building blocks that need change are:

• MappingParameters: allow to subclass to remove final annotation (alternatively, could be represented by new interface)
• MappingParametersCustomizer: new interface to allow customization of mapping parameters

    public interface MappingParametersCustomizer {
        MappingParameters from(Annotation annotation);
    }

• minor non-breaking change in MappingBuilder to accept MappingParametersCustomizer instance

      public MappingBuilder(ElasticsearchConverter elasticsearchConverter) {
          this(elasticsearchConverter, MappingParameters::from);
     }
  	
      public MappingBuilder(ElasticsearchConverter elasticsearchConverter, MappingParametersCustomizer customizer) {
          this.elasticsearchConverter = elasticsearchConverter;
          this.customizer = customizer;
      }

• MappingBuilder::InternalBuilder will use MappingParametersCustomizer instance instead of MappingParameters::from.

How it is going to work

For Spring Data Elasticsearch users - no changes in API surface. The Spring Data OpenSearch would be able to provide own MappingParametersCustomizer and MappingParameters implementation (the instances of MappingBuilder are created on demand, not as a Spring beans).

@sothawo would appreciate your thoughts here, will happily provide pull request if the feature request makes sense to you, thank you.

Reference: opensearch-project/spring-data-opensearch#626

[sothawo]

Hi Andrey,

I see no problems here. As for changing MappingParameters: Subclassing is fine for me, I would not introduce an interface here, adjust the comment for the class to mention that it needs to be open, because that's not intuitive for someone who does not know that Spring Data Opensearch derives from it.