NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

  • Created by Unknown User (endlecm), last modified on Apr 07, 2015

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Table of Contents

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. 
Then, 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 interface for the new search engine.  The LexEVS core code base would not be needed to be modified.

Approach

The approach will be to start by updating to Lucene 5.0 and fix all of the old 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.

Design

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)

  • /lbImpl/src/org/LexGrid/LexBIG/Impl/codednodeset/LuceneOnlyToNodeListCodedNodeSet.java
  • /lbImpl/src/org/LexGrid/LexBIG/Impl/codednodeset/UnionSingleLuceneIndexCodedNodeSet.java
  • /lbImpl/src/org/LexGrid/LexBIG/Impl/codednodeset/SingleLuceneIndexCodedNodeSet 
  • org.LexGrid.LexBIG.Impl.helpers.lazyloading/AbstractNonProxyLazyCodeToReturn 
  • org.LexGrid.LexBIG.Impl.helpers.lazyloading/CommonIndexLazyLoadableCodeToReturn 
  • org.LexGrid.LexBIG.Impl.helpers.lazyloading/NonProxyCodeHolderFactory 
  • org.LexGrid.LexBIG.Impl.helpers.lazyloading/NonProxyLazyCodeToReturn
  • org.LexGrid.LexBIG.Impl.helpers.lazyloading/AbstractLazyCodeHolderFactory
  • org.LexGrid.LexBIG.Impl/CodedNodeSetImpl

 

This is one example of how an interface could be created to remove Lucene objects from the LexEVS core codebase.  These methods can be pushed into an implementation of the Query interface below.  The interface would be used instead of calling Lucene directly.

Query Interface
//code decoupling

// Interface for creating Queries
public interface Query {

	// methods required for CodedNodeSetImpl 
	public  Query getCodingSchemeQuery(String uri, String internalVersionString);  
	public  Query getRestrictionQuery(Restriction restriction, String internalCodeSystemName, String internalVersionString);  

	// methods required for AbstractLazyCodeHolderFactory
	private  Query getBooleanQuery(List<Query> queries);
	public Query getFilteredQuery(List<Filter> filters, BooleanQuery combinedQuery, Filter chainedFilter);
}

// Lucene Implementation
public class LuceneQuery implements Query {

}

 

This is another example of an Interface for a ScoreDoc Factory.  AbstractLazyCodeHolderFactory.buildCodeHolder is currently using ScoreDocs.

ScoreDocFactory
public interface ScoreDocFactory {

     List<ScoreDoc> getScoreDocs (EntityIndexService service, AbsoluteCodingSchemeVersionReference ref, List<BooleanQuery> combinedQuery,List<Query> bitSetQueries);
}

 

Different types of Queries and Filter types will need to be defined as well.  We could create an abstract class for each of them.  CodedNodeSetImpl and AbstractLazyCodeHolderFactory will not need to reference Lucene objects directly then.

Abstract QueryType
// Potential abstract classes for defining different types of Lucene objects in a generic manner.
public abstract class QueryType {
}

public abstract class FilterType {
}

public abstract class FilteredQuery {
}
  • No labels