Add support for field mappings containing dots

[olada]

Elastic supports storing values in fields which contain dots (e.g. "foo.bar") (see elastic/elasticsearch#15951).

Unfortunately, spring-data-elasticsearch does not seem to support mapping such dot-containing field values using the @Field-annotation.

Cause is following lines:

spring-data-elasticsearch/src/main/java/org/springframework/data/elasticsearch/core/convert/MappingElasticsearchConverter.java

Lines 1422 to 1425 in d95af9f

	if (!fieldName.contains(".")) {
	return target.get(fieldName);
	}

The dot "." is (understandably) used for navigating the object graph.
Unfortunately the @Field-annotation does not allow overriding such behaviour (e.g. with a "navigateObjectGraphUsingDot=false" parameter or something similar).

Steps to reproduce:

• Store document containing a field which contains a dot (e.g. "foo.bar")
• Create document mapping using spring-data-elasticsearch using @field("foo.bar")
• Read documents with a repository

Behaviour:
The value of the entity which is mapped with @field("foo.bar") is null and does not contain the actual value from the elastic document

[sothawo]

I'll have to check if this might conflict with logic from spring-data-commons.

[sothawo]

details in the pull request description

[olada]

Hi @sothawo,

thanks for the super fast fix!

Can you explain how to differ between navigating the object graph using dot-notation vs direct field access for a dotted field?
I would've expected an additional property within the @Field-annotation - but the value for hasExplicitFieldName is automatically derived.

Thanks in advance!

[sothawo]

An ElasticsearchPersistentProperty has basically two names: the property name, which is the name used in the Java object, and the fieldname which is used in Elasticsearch. Normally they are the same, but there also could be a FieldNamingStrategy be set in the configuration (camel-case or snake-case). And there is the name attribute in the @Field annotation which explicitly defines a name that overrides the other ways to get the field name.

This fieldname is used at multiple places:

• when writing the index mapping
• when converting an entity into the document representation for Elasticsearch
• when reading from Elasticsearch to the entity
• when a CriteriaQuery is preprocessed. Criteria uses the entity property names and they must be mapped.

For StringQuerys and NativeQuerys this prepocessing is not possible, here the user must use the fieldname directly.

Navigating the object graph is done by Spring Data on method name resolution and that needs the Java property names, so no conflict here, under the hood this builds a CriteriaQuery which can be processed to have the filednames set.

So the explicit field name is not used anywhere where object property trees are considered.

What does not work of course is reading a nested structure coming from Elasticsearch into properties with dotted field names. For this you'd still need a nested object structure as well.