lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: [jira] Commented: (LUCENE-1290) Deprecate Hits
Date Tue, 20 May 2008 23:11:08 GMT
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.

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

View raw message