VMware offers training and certification to turbo-charge your progress.Learn more
Spring Data Elasticsearch is one of the community modules shipped with the 2020.0 release. On behalf of P.J. Meisch, who is doing most of the heavy lifting these days, we’re happy to share his insights on the current release.
The previous release included major overhaul of the internal code structure and the API, whereas the 2020.0 version of Spring Data Elasticsearch focused on fixing bugs and adding functionality.
Altogether there were 23 bugs fixed and 81 other issues resolved. Spring Data Elasticsearch now is built with the actual Elasticsearch version 7.9.3.
This blog post shows the most important features that were added to Spring Data Elasticsearch in version 4.1.
This release adds the missing pieces to have index management available from within the application, especially alias handling and index templates.
The methods for alias handling in the
IndexOperations interface have been redesigned to follow the Elasticsearch API for handling aliases. We now offer all the alias actions that Elasticsearch has in its API as well.
Index templates in Elasticsearch define mappings, settings and alias information in combination with an index name pattern. So one can define a template for an index name pattern like "log-*", and whenever an index like "log-2020-11-01" is created, the predefined mappings, settings and alias settings are automatically applied to the index.
Spring Data Elasticsearch now supports the management of index templates so the same entity annotations that are used for mappings and settings when creating an index are used for defining index templates.
With this index management it now is possible to implement index naming strategies like rolling indices with time based index names.
The index management functions now are available for the reactive setup as well as as for the non-reactive one.
On of the possibilities to define queries in Spring Data Elasticsearch is by using the
Criteria query API. It allows for a fluent, language like syntax:
Criteria criteria = new Criteria("lastName").is("Smith") .and("firstName").is("Emma"); Query query = new CriteriaQuery(criteria);
Up to now it was not possible to build nested queries with this API. If the user wants to search for all persons that have a last name of Smith and a first name of either Emma or Lucy, one might use the following query:
Criteria criteria = new Criteria("lastName").is("Smith") .and("firstName").is("Emma") .or("firstName").is("Lucy");
But this would return Emma Smith and no Lucy, because this would be mapped to "must be Smith and must be Emma and should be Lucy".
We now support nested Criteria definitions:
Criteria emmaOrLucy = new Criteria() .or("firstName").is("Emma") .or("firstName").is("Lucy"); Criteria criteria = new Criteria("lastName").is("Smith") .subCriteria(emmaOrLucy);
With these subcriterias it is now possible to build arbitrarily nested complex queries without using the
NativeSearchQuery or the
Spring Data Elasticsearch now finally supports the geo_shape datatype. A property of an entity now is interpreted as a geo_shape property if it either is derived from the newly introduced
GeoJson interface or if it is annotated with the
Spring Data Elasticsearch provides the following implementations for the
For a property annotated with
@GeoShapeField that does not implement
GeoJson one must provide custom converters for converting to and from a
Document object or
geo_shape properties are considered at the following places:
1. mappings definitions
a property defined as geo_shape will be written to the index mappings with type geo_shape, so that Elasticsearch recognizes the data as GeoJson data.
2. properties mapping
when document with a property of type geo_shape is written to Elasticsearch, the property will be converted to the corresponding GeoJSON representation, and when a search response is read, the appropriate
GeoJson derived type will be instantiated. So the geo_shape types can be used like any other property type in an entity.
3. criteria queries
Queries for geo_shape properties can be built with the
NativeSearchQuery and the
QueryString classes; besides that, the
Criteria interface now has methods to build such queries like:
CriteriaQuery query = new CriteriaQuery(new Criteria("area").intersects(geoShape));
where area is a geo_shape property and geoShape some variable of type
Criteria methods for geo_shape conditions are within, intersects, isDisjoint and contains, the same as offered by Elasticsearch for geo_shape queries.
Auditing support that was introduced in version 4.0 now is fully supported in the reactive stack as well.
When a nested query with inner hits, the inner hits are now returned in the
This was a short overview over the main changes in Spring Data Elasticsearch 4.1, we hope you enjoy using it!