Tips

In order to reduce the extra learning burden for developers, we try to keep the syntax almost the same as MP, but in order to avoid ambiguity, there are still some differences in some places. After all, ES and MySQL are different in many places. After these differences and reasons, you will certainly agree with the necessity of this difference.

1. Naming differences

In order to distinguish the ambiguity caused by the naming of MP, we added the letter Es to distinguish it from MP in the following three names:

	MP	EE	Reason for Difference
Startup class annotations	@MapperScan("xxx")	@EsMapperScan("xxx")	MP and EE may be used in a project at the same time, to avoid the need to add full path distinction when introducing annotations with the same name in the same system
Name of parent class Mapper	BaseMapper<T>	BaseEsMapper<T>	MP and EE may be used in a project at the same time, to avoid the Mapper inherited from MP by mistake
Condition constructor naming	LambdaQueryWrapper	LambdaEsQueryWrapper	MP and EE may be used at the same time in a project to avoid mistakenly creating conditional constructors

2. Removed Service

The Service layer is introduced in MP, but there is no Service layer in EE, because I personally think that the Service layer of MP is too heavy and not flexible enough. , You don't need to inherit ISevice like MP in the process of use. In addition, I have sunk some frequently used service layer encapsulation methods to the mapper layer, such as batch update, batch addition, etc. You can call the base class Mapper layer in the The method is flexible and elegant.

3. Method differences

When group by aggregation uses the groupBy method in EE, the query interface must be called to obtain the native return content, and the generic T cannot be returned like in MP. This is due to the difference between ES and MySQL, so special attention should be paid to it.

LambdaEsUpdateWrapper<T> wrapper = new LambdaEsUpdateWrapper<>();
wrapper.groupBy(T::getField);

// MP syntax
List<T> list = xxxMapper.selectList(wrapper);
// EE syntax
SearchResponse response = xxxMapper.search(wrapper);

Because Es will put the aggregated results into the aggregations object separately, but the original entity object does not have this field, so we need to use SearchResponse to receive the results returned by the query, and all the query information we need can be obtained from SearchResponse.

"aggregations":{"sterms#creator":{"doc_count_error_upper_bound":0,"sum_other_doc_count":0,"buckets":[{"key":"Old Man","doc_count":2},{"key": "Pharaoh","doc_count":1}]}}

Removed a few methods that I haven't seen use cases yet:

having(String sqlHaving, Object... params)
having(boolean condition, String sqlHaving, Object... params)
func(Consumer<Children> consumer)
func(boolean condition, Consumer<Children> consumer)

Added some methods that EE has but MP does not support:

// index creation related
Boolean existsIndex(String indexName);
Boolean createIndex(LambdaEsIndexWrapper<T> wrapper);
Boolean updateIndex(LambdaEsIndexWrapper<T> wrapper);
Boolean deleteIndex(String indexName);

// Weights
function(field, value, Float weight value)

// Geo location related
geoBoundingBox(R column, GeoPoint topLeft, GeoPoint bottomRight);
geoDistance(R column, Double distance, DistanceUnit distanceUnit, GeoPoint centralGeoPoint);
geoPolygon(R column, List<GeoPoint> geoPoints)geoShape(R column, String indexedShapeId);
geoShape(R column, String indexedShapeId);
geoShape(R column, Geometry geometry, ShapeRelation shapeRelation);

// other...

Except for the small differences listed above, there is no obvious difference between the rest and MP, and users can use EE just like MP