lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Controlling Hits
Date Mon, 27 Nov 2006 22:06:19 GMT

: In fact, I fail to see a situation where "Hits"'s concept of "random access"
: to the results (you can ask for result #30 and then #70) even makes sense.
: In all search applications I'm familar with, at the time you call search(),
: you already know how many results you want to display - and you don't need
: someone to guess for you that you need 50 results, and if that's not enough
: then you need 100 results, and then 200, and so on.

Hits attempts to do the best it can for a simple clients without forcing
the client to use an API that requires knowing exactly how it will get
used in advance of executing hte search -- this can be practical in a
simple MVC framework where the Contorller may not know exactly how the
View wants to display things; if the Controller is forced to tell the
Searcher how many results it wants and at what offset, then that's one
more place that information has to be used (instead of in just hte View)

as for the random access: imagine you are outputing a multi column listing
of N results per page, using an HTML table: you display # 1, then # N/2+1,
then a row boundry, then # 2, then # N/2+2, etc... likewise imagine you
want to prefetch some data baout each item on your "page" so you iterate
over all of them once to get their image path (or something) then you
iterate over all of them again to display the results.

...there are lots of possible usecases, and that's what Hits is all about:
making it trivially easy for people do do just about anything with a
really simplistic API -- without concern for performance.   once
performance becomes your concern, then you start reconsidering your API,
and have to understand more about the Lucene internals to make the right
choice for your application.

I hate the Hits class with a passion -- almost as much as I hate the
RangeQuery class -- i have yet to read/hear a question asked for which i
thought "Hits" was the right answer ... but i don't think we should ever
deprecate it unless it's because we've aded an even *simpler* API ...
Like QueryParser, StandardAnalyzer, IndexMOdifier, and the IndexSearcher
constructor that takes a "String" arguement, Hits provides a super low
barrier to entry that lets people start writting Lucene apps without
needing to understand the complexities of the underlying Lucene APIs



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message