lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hang Li <...@careersite.com>
Subject Re: CachedSearcher
Date Tue, 16 Jul 2002 14:01:58 GMT
Halácsy Péter wrote:

> Hello!
> A lot of people requested a code to cache opened Searcher objects until the index is
not modified. The first version of this was writed by Scott Ganyo and submitted as IndexAccessControl
to the list.
>
> Now I've decoupled the logic that is needed to manage searher.
>
> The usage is very simple:
> IndexSearcherCache isc = new IndexSearcherCache(new File("/path/to/the/index"));
> for(int i= 0; i++; i< 100) {
>   Searcher searcher = isc.getSearcher();
>   // search here
>   searcher.close();
> }
>
> only one Searcher will be opened here if no other thread is writing the index; if the
index was modified getSearcher() will close the old one and create a new.
>
> Unfortunatly to compile and use this code one has to modify the lucene source:
>
> 1. change all package-protected abstract method to public in Searcher.java
>
>   /** Frees resources associated with this Searcher. */
>   abstract public void close() throws IOException;
>
>   abstract int docFreq(Term term) throws IOException;
>   abstract int maxDoc() throws IOException;
>   abstract TopDocs search(Query query, Filter filter, int n)
>        throws IOException;
>
>   /** Frees resources associated with this Searcher. */
>   public abstract  void close() throws IOException;
>
>   public abstract int docFreq(Term term) throws IOException;
>   public abstract int maxDoc() throws IOException;
>   public abstract TopDocs search(Query query, Filter filter, int n)
>        throws IOException;
>
> 2 change package protected TopDocs to public (in TopDocs.java)
> final class TopDocs {  --> public final class TopDocs {
>
> Or you can use the modified files I've attached.
>
> I hope this code is helpful.
>
> The main idea to have an interface SearcherSource something similar to DataSource in
javax.sql. SearcherSource is responsible for creating searcher object. One implementation
is SearcherCache that encapsulates the logic of caching searcher. IndexSearcherCache - as
you might figure out - can cache IndexSearcher objects. Someone could implement a MultiSearcherCache
class that manages... (recreates the searcher if one of the searchers need reopening).
>
> I create IndexSearcherCache in my init method and pass the object as a SearcherSource
to the working methods. In the destroy process I call release() method. In this way I can
later change the implementation of the cache as far as it implementing SearcherSource.
>
> peter
>
> ps: of cource you can change the code, class/method/package/.. names;
> Unfortunatly a lot of System.out.println debugging code is used but it is very good to
understand the behaviour.
>
>   ------------------------------------------------------------------------
>                             Name: CachedSearcher.zip
>    CachedSearcher.zip       Type: Zip Compressed Data (application/x-zip-compressed)
>                         Encoding: base64
>                      Description: CachedSearcher.zip
>
>                       Name: TopDocs.java
>    TopDocs.java       Type: unspecified type (application/octet-stream)
>                   Encoding: base64
>                Description: TopDocs.java
>
>                        Name: Searcher.java
>    Searcher.java       Type: unspecified type (application/octet-stream)
>                    Encoding: base64
>                 Description: Searcher.java
>
>    Part 1.5Type: Plain Text (text/plain)

I am new here, I am sorry if this question has been asked before. Why there are so many final
and package-protected methods?  I want to change the way TermQuery doing scores. Ideally,
I would like to have  subclasses of TermQuery and TermScorer, and place them in my OWN package.
Currently, I have to put these two in lucene, and I have to copy almost every line of the
TermQuery class into my new query class except the line returns Scorer. Note, this
may be a bad example, but I still want to know if we can make Lucene more extendable from
outside in the future.


--
To unsubscribe, e-mail:   <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>


Mime
View raw message