[
https://issues.apache.org/jira/browse/LUCENE-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931678#comment-13931678
]
Michael McCandless commented on LUCENE-5519:
--------------------------------------------
Hmm, I don't like that we pre-allocate the full array[topN] here. Can we just
use a List<X> for the input/output pairs? Or maybe just to back to
List<MinResult>?
It's also sort of strange to have spaceNeeded/isFull methods: it makes this
class more like a queue and less like a set of final results. I'd prefer if it
were more like TopDocs: its purpose is to simply deliver results. I think
those methods/queue state tracking should be outside of that class.
> Make queueDepth enforcing optional in TopNSearcher
> --------------------------------------------------
>
> Key: LUCENE-5519
> URL: https://issues.apache.org/jira/browse/LUCENE-5519
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/FSTs
> Affects Versions: 4.7
> Reporter: Simon Willnauer
> Priority: Minor
> Fix For: 4.8, 5.0
>
> Attachments: LUCENE-5519.patch, LUCENE-5519.patch
>
>
> currently TopNSearcher enforces the maxQueueSize based on rejectedCount +
> topN. I have a usecase where I just simply don't know the exact limit and I
> am ok with a top N that is not 100% exact. Yet, if I don't specify the right
> upper limit for the queue size I get an assertion error when I run tests but
> the only workaround it to make the queue unbounded which looks odd while it
> would possibly work just fine. I think it's fair to add an option that just
> doesn't enforce the limit and if it shoudl be enforced we throw a real
> exception.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
