[ 
https://issues.apache.org/jira/browse/LUCENE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889559#action_12889559
 ] 

Woody Anderson commented on LUCENE-2542:
----------------------------------------

Well, the idea of "top N documents" is, imo, distinct from how it is 
implemented, (e.g. with lucene's internal PQ impl).

I think, at some level we disagree on what TopDocsCollector is "for", you say 
it's for a PQ implementation; whereas, I think it's for the public interface, 
namely:
getTopDocs(..) and getTotalHits(). The that fact that the implementation uses 
org.apache.lucene.util.PriorityQueue is not necessarily a positive thing for my 
purposes.

Alternate impls certainly could subclass Collector directly, but much of the 
time when getting documents, getting a TopDocs is preferred, and there is value 
in expressing that capability abstractly. And there is value in expressing 
accomplishing that w/o being tied it to a single possible implementation. 
Overall, the PQ based impl is effective, but that doesn't mean that it's always 
the most effective impl capable of yielding TopDocCollector functionality, and 
by that i mean the public interface.

I have uses of this code that require referring abstractly to Collectors that 
produce TopDocs, doing that without any common interface or abstract class 
(whole separate issue with the fact that Collector is not in iface & ditto TDC) 
requires wrapping a TopDocsCollector in a proxy, which is just kind of silly to 
me.

Also, i'm entirely missing the downside?

> TopDocsCollector should be abstract super class that is the real 
> "TopDocsCollector" contract, a subclass should implement the priority-queue 
> logic. e.g. PQTopDocsCollector
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2542
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2542
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 3.0.2
>            Reporter: Woody Anderson
>             Fix For: 4.0
>
>         Attachments: LUCENE-2542.patch, LUCENE_3.0.2-2542.patch
>
>
> TopDocsCollector is both an abstract interface for producing TopDocs as well 
> as a PriorityQueue based implementation.
> Not all Collectors that could produce TopDocs must use a PriorityQueue, and 
> it would be advantageous to allow the TopDocsCollector to be an "interface" 
> type abstract class, with a PQTopDocsCollector sub-class.
> While doing this, it'd be good to clean up the generics uses in these 
> classes. As it's odd to create a TopFieldCollector and have to case the 
> TopDocs object, when this can be fixed with generics.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Reply via email to