lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrzej Bialecki>
Subject Re: [jira] Commented: (LUCENE-1290) Deprecate Hits
Date Wed, 21 May 2008 09:24:15 GMT
Mark Miller wrote:
> Michael Busch (JIRA) wrote:
>>     [ 

>> ]
>> Michael Busch commented on LUCENE-1290:
>> ---------------------------------------
>> {quote}
>> A replacement could be an API which allows something like:
>> for(Iterator<ScoreDoc> it = searcher.iterator(query); it.hasNext(); ) 
>> { (...) if (...) break; }
>> {quote}
>> That would duplicate the search methods that use a HitCollector.
>> I still don't understand why an iterator approach is better/easier
>> than Lucene's callback (HitCollector) approach.
> I think its a lots harder to misuse things when using what I think used 
> to be labeled as the *expert* api (HitCollector). Hits attempts to make 
> things easier for the new comer, but its so easy to misuse the class 
> that I think new comers often don't have the knowledge to use it well. 
> It does not make a great default.
>  >> FWIW, the Hits API was originally designed to support desktop 
> applications, with a scrollable pane of hits. I wonder if anyone ever 
> actually used >>it that way, and, if so, whether it worked well...
> And thats the limited thing that Hits is good for...a single user 
> experience. Lucene is so heavily used in a multi threaded, multi-user 
> environment, that often Hits caching and pre-fetching are pretty 
> worthless at the Hits level. Its not a good class for a new user that 
> doesnt understand it limitations and its not a good class for the 
> general search case.
> I don't know if I necessarily agree the whole class has to go (that will 
> annoy plenty that use it, and we will prob force a lot of individuals to 
> maintain it themselves), but I think it sure should lose its emphasis as 
> the goto search class for new Lucene users.

Another idea ... why not keep a modified, but crippled Hits class, so 
that it's obvious that it's only good for a limited use?

Specifically, we could remove the re-searching mechanism from Hits, so 
that it can only provide up to e.g. top 100 results, and throw 
exceptions beyond that number. This way users that only ever need the 
top 100 results can still use Hits, but it will be obvious for others 
that they should move to using the HitCollector API.

Best regards,
Andrzej Bialecki     <><
  ___. ___ ___ ___ _ _   __________________________________
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration  Contact: info at sigram dot com

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message