Lucene-based case development: search methods in IndexSearcher,

Lucene-based case development: search methods in IndexSearcher,
Reprinted please indicate the source: http://blog.csdn.net/xiaojimanman/article/details/43052829
We have introduced Analyzer and Query before. In this article, we will start to introduce the search API of the last class IndexSearcher in this series. The key API in Lucene is not only described here, there are also IndexWriter, Field, and Highlighter. These are not described in this section. If they are used in this case, we will give a brief introduction.
To view the IndexSearcher API in javase4.3.1, click here. The search method is as follows:

From several methods, we can see that there are several important categories that need to be introduced: Query (introduced in the previous blog), Filter, Sort, ScoreDoc, Collector

Collector
Collector is mainly used to collect, customize sorting, and filter search results. In the API of javase4.3.1, two search methods are used by Collector, however, there is a Lower-level search API (low-level search API) below. If there is no need for unavailability, try to use other methods.

Filter
Filters are mainly used for filtering conditions. They are used to specify which documents can be found in the search results. They are not used too much and query some information, this section describes how to Filter the data source before filtering the data source (specified in the Filter), and then submit the filtering result to the query statement. If so, the cost of using Filter is high, and the query time may be increased several times. I personally think that there is no need to use filters. If you really need to Filter the results, you can combine these filtering conditions into the Query, and there is no need to create a Filter object.

Sort
Sort specifies the sorting method in the retrieval method, which is equivalent to order by in the database. The creation method is as follows: Sort sort = new Sort (new SortField ("time", Type. LONG, true). The three parameters in the SortField constructor represent the domain name, domain data type, and sorting method (true descending/false ascending ), the example here only sorts by one domain. If multiple domains can be added directly in the constructor, such as sort = new Sort (new SortField ("time", Type. LONG, true), new SortField ("star", Type. INT, false )).

ScoreDoc
From the method, ScoreDoc is used in the searchAfter method. This method is mainly used in paging queries. Of course, it can also be replaced by the search method, but there is a situation that cannot be replaced, for example, if you want to query 10 pieces of data on the first page, you need to add several (unknown) other records to it due to the need for promotion or advertisement. However, the front-end can only display 10 pieces of data, in this way, there is no way to display the last few pieces of data on the page, but you want to display these pieces of data on the next page. It is difficult to use the seach method. The graphic description of the case requirement is as follows:

When searchAfter meets the preceding requirements, when retrieving the next page of data, you only need to tell the last ScoreDoc In the last query to query the next page of data directly from the data.

The classes involved in the search method are also completed. Now we will assemble these classes. Take the simplest search Method as an example: search (Query query, int n ), this method is used to retrieve the first N documents that meet the condition query. The sorting here adopts the default relevance sorting. In this way, other objects are added to the method, the corresponding functions are completed, such as search (Query query, int n, Sort sort). This method specifies the sorting method. This blog mainly introduces the search-related API of IndexSearcher, so I will not write a test demo here.

IndexWriter
The first part of the original plan should end now, and do not introduce other content. However, the reader's feedback shows that the method for adding, deleting, and modifying indexes is not very clear, here is a simple question. If you are interested, add a new document to the index. This is already mentioned in the index creation blog, I will not introduce it here.
Modify Index

public boolean updateDocument(Term term, Document doc){try {indexWriter.updateDocument(term, doc);return true;} catch (IOException e) {e.printStackTrace();return false;}}

Here, the term specifies the index document to be modified. Generally, the unique identifier of the document in the index is used here.
Delete Index

public boolean deleteDocument(Query query){try {indexWriter.deleteDocuments(query);return true;} catch (IOException e) {e.printStackTrace();return false;}}

The query specifies the conditions that must be met by the Document. Of course, you can also clear the index directly.

public boolean deleteAll(){try {indexWriter.deleteAll();return true;} catch (IOException e) {e.printStackTrace();return false;}}

These operations must be saved after indexWriter. commit () is executed. Otherwise, they will not be valid.


Note: Part 1: the basic principles of lucene and the use of simple API interfaces end here. Data collection should be introduced in the next part of the data flow, however, in order to introduce the knowledge of lucene in the search background, we will make the search background a little more advanced here. Before I start searching for the background, I will also introduce the demo of this case and the background system architecture in 1-2 blogs. On the basis of a certain understanding of the entire requirement, let's start case development. If you have any comments on the layout or content of your blog, I sincerely hope you can mention it in the comments. I will also actively adopt your suggestions, make good use of this series of blogs and make common progress.


Ps: I recently found that other websites may repost the blog, and there is no source link above. If you want to view it