 |
Page History
| Scrollbar | ||
|---|---|---|
|
| Panel | ||
|---|---|---|
| ||
Author: Craig Stancl, Scott Bauer, Cory Endle |
| Panel | ||
|---|---|---|
| ||
|
Goal
The goal of the decoupling work is to remove references of the Lucene search implementation from the LexEVS API layer. In the current implementation of LexEVS, Lucene objects are currently embedded in the LexEVS code base.
Work would be done to model and refactor much of the LexEVS search to remove references of Lucene. This would be done by creating a search interface that would be implemented to bridge LexEVS to the search. We would then create a search implementation using Lucene.
Reasons for decoupling are:
- This is a "best coding practice" - the search specific implementation of Lucene should not be embedded in the LexEVS code base. This work, whether it is completed or not will have no impact on the overall Lucene 5.0 implementation.
- The decoupling task will move the search specific code to an implementation of a new search interface. If the need ever arose to swap out Lucene for a different search engine, we would be able
- to create a new implementation of the search interface
- with the new search engine
Approach
- and not have to make changes in the LexEVS code base.
Recommendation
Based on our review of the code and the large effort needed to complete this decoupling task, we recommend that this decoupling task be lowered in priority and postponed until the main Lucene 5.0 implementation is complete. At this time we can consider if we should take on this task.
Approach
Before we look at the decoupling task, the approach will be to first update The approach will be to start by updating to Lucene 5.0 and fix all of the old references old Lucene references to get the new Lucene working. Once this is complete, we will next look at decoupling Lucene from the LexEVS API layer. This is described in more detail below.
Lucene objects are interspersed in many parts of the LexEVS. This will not be a quick process. This is a large modeling and refactoring task. This work can be accomplished after Lucene 5.0 is working or can be a separate task to complete in the future.
After looking at the entire Lucene upgrade project architecture, we will need to decide if there is time to pursue this decoupling task.
...
We will need to upgrade to Lucene 5.0 first because there will be a lot of Lucene API changes as well as some obsolete Lucene objects that will need to be removed or replaced. If the decoupling task was done before this with the existing Lucene version, we would have to make additional changes once Lucene 5.0 is implemented.
Once the Lucene 5.0 implementation is complete, we should discuss the priority of this task again.
Design
In order to remove the Lucene references from the LexEVS core code base, we will design a new search API interface. We would then be able to create a specific Lucene implementation of this interface. If there was ever a need to substitute different search engine, all that would be necessary would be to create a new implementation of the search API interface for the new search engine. The LexEVS core code base would not be needed to be modified.
There are several classes that will need to evaluated when doing the actual implementation. These cases include code where Lucene objects are intermixed throughout LexEVS methods. (This is not an all inclusive list)
...
