Refactoring of IndexSearcher [LUCENE-7902]
- Dominant language
- Java
- Stars
- 3.6k
- Forks
- 1.4k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 88
Description
Hello everyone.
I was analyzing the modularization of some classes, and I identified that the class IndexSearcher has an opportunity for cohesion improvement.
The class IndexWriter was in the same situation and the problem was solved as follows: The IndexWriterConfig class was created, and several get() and set() methods that were used only to configure the class parameters were moved from IndexWriter to IndexWriterConfig.
The new class was then accessed through an instance variable in IndexWriter. This strategy has cleaned and improved IndexWriter cohesion.
With this in mind, I would recommend creating a new class: IndexSearcherConfig , and moving the following methods:
setDefaultQueryCachingPolicy
getDefaultQueryCachingPolicy
getQueryCachingPolicy
setQueryCachingPolicy
setQueryCache
getQueryCache
setDefaultQueryCache
getDefaultQueryCache
setSimilarity
getSimilarity
from the IndexSearcher.
Those parameters accessed by an instance variable in the IndexSearcher.
Moreover, the orthogonality is the design would be enhanced.
What do you think about that?
---
Migrated from [LUCENE-7902](https://issues.apache.org/jira/browse/LUCENE-7902) by João Paulo Lemes Machado, updated Aug 10 2017
Contributor guide
Research direction
Start by reading the IndexSearcher class and comparing its configuration methods with the IndexWriterConfig approach described in the issue. Review the listed cache and similarity methods, then determine whether an IndexSearcherConfig can hold them without changing behavior. Done means the configuration responsibilities are separated while IndexSearcher continues to use them correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- search
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100