lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Woody Anderson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2542) TopDocsCollector should be abstract super class that is the real "TopDocsCollector" contract, a subclass should implement the priority-queue logic. e.g. PQTopDocsCollector
Date Sun, 18 Jul 2010 04:22:49 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message