[
https://issues.apache.org/jira/browse/LUCENE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16556397#comment-16556397
]
Hoss Man commented on LUCENE-8060:
----------------------------------
{quote}On the other hand I'm concerned that the "nothing" approach is not very
usable in practice as it is hard to build a UI with pagination, which I see is
a very common need. ...
{quote}
Oh, right – because if we default to "0" (or "-1" or whatever means "don't
track at all") the the consumer of TopDocs doesn't even know if there should be
a "next" link. yeah, i guess some arbitrary finite positive integer is the
least bad option.
{quote}... maybe we could add a setter on IndexSearcher?
{quote}
Yeah i dunno... that just feels kind of weird to me – i guess i have two straw
man concerns about that approach...
# why have a {{setDefaultNumTotalHitsToTrack(int)}} just for this concept, and
not a setter for all the other collector concepts that we currently have
defaults for in the simple search/searchAfter methods (like {{Sort sort}} ,
{{boolean doDocScores}} , {{boolean doMaxScore}} , etc...)
** do we want to go down the route of an {{IndexSearcherConfig}} ?
# this seems like it introduces divergent "intermediate APIs" for users to
learn about that might frustrate them down the road...
** Today, the first time you build an app you just call something like
{{IndexSearcher.search(myQuery, 100, mySort)}} and you're happy, and then later
if you decide you want to do something more complicated you read the docs and
learn about Collectors and you start using the builder methods to create
collectors that solve common problems, and if you get to the point that those
don't meet your needs you already understand the collector concept and you can
write your own (composing existing ones)
** if there's IndexSearcher setters that change the default behavior of the
{{search()}} methods, then that becomes the path of least resistence that
intermediate users go down to do slightly more complex things, but if they
reach the point where they want to do something new that doesn't have a setter,
they have to "start over" learning about how to do searchers, and read up on
writting/composing collectors w/o having used the out of the box collector
builds yet.
> Require users to tell us whether they need total hit counts
> -----------------------------------------------------------
>
> Key: LUCENE-8060
> URL: https://issues.apache.org/jira/browse/LUCENE-8060
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Priority: Minor
> Fix For: master (8.0)
>
>
> We are getting optimizations when hit counts are not required (sorted
> indexes, MAXSCORE, short-circuiting of phrase queries) but our users won't
> benefit from them unless we disable exact hit counts by default or we require
> them to tell us whether hit counts are required.
> I think making hit counts approximate by default is going to be a bit trappy,
> so I'm rather leaning towards requiring users to tell us explicitly whether
> they need total hit counts. I can think of two ways to do that: either by
> passing a boolean to the IndexSearcher constructor or by adding a boolean to
> all methods that produce TopDocs instances. I like the latter better but I'm
> open to discussion or other ideas?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
