Faq
Tips
In the use of the framework, it is inevitable that exceptions will occur due to various reasons. We do not rule out that the framework itself is defective (usually less than 0.1%), but the currently released functions are all stable and have test case coverage and a large number of users to verify the production environment In the past, most of the time, it is dependent on incompatibility or the user does not use it according to the document, which leads to some problems. Such users are usually lazy, and when they encounter a big problem, they immediately come to the group to ask or complain. Framework garbage, and then we assisted in the investigation and solution. Finally, we found that the xx place was not used according to the document, but was messing around. We were also helpless. After all, the energy and time of open source are relatively limited. We want to spend time on the cutting edge, such as collecting The real bugs should be solved iteratively instead of wasting time in these unnecessary places. Therefore, we still hope that users can read the document more before using it. If you encounter problems, you may start with the document to see if there are any questions you want to ask in the high-frequency Q&A provided by us, and see how the DEMO we provide is written? What is the version of es, fastjson, and springboot that DEMO actually depends on? You might as well keep the dependency version in your project consistent with the demo, and exclude the cause of the dependency. If it is still not resolved, you can break the point to find the reason, and look at the source code analysis and analysis , After these steps, if you still can't solve it, you can ask questions in the Q&A group again. This is the basic literacy of a code farmer, and it is of great help to improve your own technical level. If you encounter problems, throw them out. The ability to solve and analyze problems independently will get worse and worse. If things go on like this, if one day you use a certain open source product, and no one answers your questions, what will you do?
What should I do when there are some requirements that the API provided by EE does not support? It doesn't matter, the author has already helped the masters to think of the best solution, please check here: Mixed query
During the trial process, an error is reported: java.lang.reflect.UndeclaredThrowableException
Caused by: [daily_document] ElasticsearchStatusException[Elasticsearch exception [type=index_not_found_exception, reason=no such index [daily_document]]]
If your error message and cause are the same as above, please check whether the index name is configured correctly, check the global configuration, and the annotation configuration. If the configuration is correct, the index may not exist. You can use the es-head visualization tool to check whether the specified index already exists. , if there is no such index, it can be quickly created through the API provided by EE.
- Dependency conflict
Although the EE framework is lightweight enough, and I try to avoid using too many other dependencies during the development process, it is still difficult to guarantee that there is a very small probability that there will be a dependency conflict with the host project. Dependency conflicts can be resolved by removing duplicate dependencies or unifying the version numbers of dependencies. All possible conflicting dependencies of EE are as follows:
<dependency>
<groupId>org.dromara.easy-es</groupId>
<artifactId>easy-es-boot-starter</artifactId>
<version>1.0.3</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
</dependency>
<dependency>
<groupId>org.elasticsearch.client</groupId>
<artifactId>elasticsearch-rest-high-level-client</artifactId>
<version>7.14.0</version>
</dependency>
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<version>7.14.0</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.83</version>
</dependency>
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Can't find the data using wrapper.eq(xx::getXX, "query content")? eq corresponds to the TermQuery() of es, which can only be queried when the index type of the queried field is keyword. If the index type of the queried field is text, then the field will not be queried by eq. You may wish to look at yourself before using it. If you need word segmentation matching, set the index type of the field as text type, and then use wrapper.match(), wrapper.queryString() and other methods to query; if you need exact matching, you can use the index The field type is established as the keyword type, and then use wrapper.eq() to query; if the same field needs to be queried by exact match and by word segmentation, its index type can be created as keyword&text type, and it is regarded as keyword When querying by type, you need to pass in the field name as "field name.keyword". When querying it as a text type, you can directly use the field name. Or you may wish to make this field redundant, add a new field, the value is consistent with the field, one index uses keyword, one uses text type, so that it can be solved perfectly. For es, it supports PB-level data and adds a redundancy. fields, the performance impact is minimal.
process index exception, java.util.concurrent.CompletionException: java.lang.ArithmeticException: / by zero It is caused by the configuration of the es stand-alone version, not the framework.
Error when adding data java.lang.reflect.UndeclaredThrowableException: null 99% of the time, you use a nested object in your entity class, but the annotation on the object is actually specified as @IndexField(fieldType=Object). Nested objects must use the syntax of nested objects, refer to the document [nested types] (/pages/05702c/), the remaining 1% cases are caused by the fact that the version of fastjson dependencies actually introduced in your project is too low/high. The demo provided by me is consistent or consistent with the fastjson version that the framework relies on at the bottom.
When calling the insert or insertBatch interface, an error is reported the entity id must not be null Check whether the global id policy id-type in the configuration file is customize, and whether the idType value in the @IndexId annotation is IdType.CUSTOMIZE. If this value is set, it means that the id is passed in by the user, so the user needs to take the initiative before inserting data. Set a value for the id of that data before inserting.
Error java.lang.NoClassDefFoundError...AliasMetadata when project starts Specific error content process index exception,java.util.concurrent.CompletionException: java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: org/elasticsearch/cluster/metadata/AliasMetadata If this error message appears, it means that the version of es and Resthighlevelclient jar that you actually depend on in your current project is too low. It is recommended to upgrade to version 7.10+ (recommended 7.14.0, which is consistent with the dependency version used at the bottom of the framework, and has the best compatibility), can be solved.
The index name appears in the index with _s0 or _s1 suffix Don't worry, this is the only way to fully automatic and smooth migration with zero downtime. The index suffix does not affect the use, and the framework will automatically activate the new index. Regarding the _s0 and _s1 suffixes, it is unavoidable in this mode, because it is necessary to keep the original Index data migration, and two indexes with the same name cannot exist at the same time. For the complete principle, please refer to the Index Processing chapter.
The index will be appended with the alias ee_default_alias Don't worry, each index can have N index aliases. This alias is mainly used to facilitate the bottom layer of the framework to manage the indexes automatically managed by the framework. It is equivalent to labeling the index. It is an appending mechanism and will not affect your existing Indexing aliases is like your real name is an old man, someone else gave you a nickname called a macho,a bad old man, a handsome guy... It does not affect your real identity as an old man.
Does it support cross-index CRUD? In the case of the same index structure, the user can specify the effective index of the current operation in wrapper.index(indexName1, indexName2...). If the method has no wrapper, it can be directly passed in the corresponding interface, such as insert(entity, indexName1, indexName2 ...), the index structure must be the same, otherwise it cannot be executed successfully, This function is suitable for users whose index structure is generated by date, such as by month, by year, but the index name is different, but the index structure is the same, this solution can be used to solve the confusion in CRUD.
Why is the index type specified by @ IndexField annotation keyword (or other types), but the index type actually created is as shown in the figure below? Why? ! image2 (opens new window)
- First, you need to confirm that the current index is enabled in the "automatic mode", which is enabled by default. If it is in the manual mode, the index type specified in the custom annotation will only take effect in the following two apis, and will not take effect for purely customized scenarios
Boolean createIndex();
Boolean createIndex(String indexName);
2
Because in a purely customized scenario, in order to ensure the native flexibility, all information such as the index type is specified by the user, not user-defined annotations
- Secondly, you need to confirm whether the index is created successfully in the automatic transmission mode or the above two APIs. The symbol of successful index creation is that the console prints the Configurations auto process index by Easy Es is done!
If the console prints===>Unfortunately, auto process index by Easy Es failed..., the index hosting has failed. The specific reasons can be found in the logs that follow. Of course, 99.99% of the community's questions have been answered for so long. These are the following two reasons:
- The underlying es or RestHighLevelClient depend on conflicting versions. Because the EE underlying es and RestHighLevelClient depend on 7.14.0 versions, and the ES version is not compatible, Springboot has springdata es, so it has a built-in version corresponding to es, so it is inevitable that the es dependency conflicts caused by different versions of springboot will occur, leading to incompatibility of many functions, leading to index hosting failure, The es and RestHighLevelClient versions can be unified to 7.14.0. If not, please rely on Baidu to solve the conflict. This is the basic skill of a Java programmer. If you don't know how to learn it, I really block Q and don't ask me such low-level questions again!
- The entity class uses [Nested] (/pages/6dbf71/), but it is not configured according to the usage document of the nested type. As a result, index hosting fails. Many people do not know what the nested type is. To put it simply, you have introduced other user-defined objects or maps into your entity class
- The entity class uses the wrapper types such as List<String | Integer...>. At this time, the index type of this field should be defined as text rather than array. When querying, you can query through wrapper.match. The es default word breaker will find the specific data through the comma in the array
Then some users wonder why you said the index hosting failed, but the index actually exists, which can also be seen through es head, and the type of this field is keyword&text. This is because when the field does not exist, if you call the data insertion/update api, es itself (not easy es) will help you automatically create an index. The default type of the created index field is keyword&text
- Why can't data be found through eq? Can't find data through match? Can't find data through xxx? First of all, you should make it clear that eq corresponds to es termQuery, and match corresponds to matchQuery... For details, refer to [Difference from MP] (/pages/98dad3/) The term query requires that the field type is keyword, and the matchQuery requires that the field type is text. If it is Chinese, you need to install a Chinese word breaker, such as ik, and then create and configure it correctly in the index to find it If you can't find out, you might as well check whether your index type, word breaker, and word breaker can distinguish the keywords you input, whether the original text can be hit, and whether the same word breaker is used for storage and query. You need to confirm first, instead of coming up to question whether the framework has bugs. The functions that the framework has been launched are all covered by single test and used by a large number of users, otherwise it will not be launched easily