New

The executive guide to generative AI

Read more
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Relation names inference

edit

Relation names

edit

Prior to Elasticsearch 6.x you could have multiple types per index. They acted as a discrimatory column but were often confused with tables. The fact that the mapping API’s treated them as seperate entities did not help.

The general guideline has always been to use a single type per index. Starting from 6.x this is also enforced. Some features still need to store multiple types in a single index such as Parent/Child join relations.

Both Parent and Child will need to have resolve to the same typename to be indexed into the same index.

Therefore in 6.x we need a different type that translates a CLR type to a join relation. This can be configured seperately using .RelationName()

var settings = new ConnectionSettings()
    .DefaultMappingFor<CommitActivity>(m => m
        .IndexName("projects-and-commits")
        .RelationName("commits")
    )
    .DefaultMappingFor<Project>(m => m
        .IndexName("projects-and-commits")
        .RelationName("projects")
    );

var resolver = new RelationNameResolver(settings);
var relation = resolver.Resolve<Project>();
relation.Should().Be("projects");

relation = resolver.Resolve<CommitActivity>();
relation.Should().Be("commits");

RelationName uses the DefaultTypeNameInferrer to translate CLR types to a string representation.

Explicit TypeName configuration does not affect how the default relation for the CLR type is represented though

var settings = new ConnectionSettings()
    .DefaultMappingFor<Project>(m => m
        .IndexName("projects-and-commits")
    );

var resolver = new RelationNameResolver(settings);
var relation = resolver.Resolve<Project>();
relation.Should().Be("project");
Was this helpful?
Feedback