/**
* [[relation-names]]
* [float]
* === Relation names
*
* 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()`
*/
[U] public void RelationNameConfiguration()
{
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
*/
[U] public void TypeNameExplicitConfigurationDoesNotAffectRelationName()
{
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");
}
public string RelationName(RelationName type) => RelationNameResolver.Resolve(type);
public string RelationName <T>() => RelationNameResolver.Resolve <T>();