On Dec 19, 2004, at 5:05 PM, Steve Skillcorn wrote:
I bought the Lucene in Action ebook, which is excellent and I can strongly recommend.
Thank you!!!!
Does the IndexReader that is passed to the “bits” method of the filter represent the entire index, or just the results that match the query?
It represents the entire index at the time it was instantiated. This is important to know in case documents are later added to the index.
Is not worrying about filters and simply checking the returned Hit List before presenting a sensible approach?
It depends. Is the performance of checking a relational database for the results being shown to the user acceptable? Is the security risk of a new piece of code forgetting to check the results of a search worth it?
I can see the point to filters as presented in the Lucene in Action ISBN example, but are they a good approach where they could end up laboriously marking the entire index as True?
Iterating through every document in the index certainly is time consuming and not something you should do for every search. However, filters are designed to be long-lived. Write your filter to simply do the logic of checking each document against the database, then wrap your filter with the caching wrapper. Be sure to use the same IndexReader for each search. When the index changes, rebuild the filter.
There is no clear best way to do this type of filtering of results, I don't believe. There are details to consider for either of these approaches.
All help greatly appreciated. Thanks to the authors for Lucene in Action, it's given me the high level best practices I was needing.
Steve - I really appreciate hearing this. Putting this work to public scrutiny opens the possibilities of opinion. Your comments hearten me.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
