[ 
https://issues.apache.org/jira/browse/LUCENE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woody Anderson updated LUCENE-2542:
-----------------------------------

    Attachment: LUCENE-2542.patch

this patch was generated against lucene/trunk
{code}
~/g/lucene-trunk -> svn info
Path: .
URL: http://svn.apache.org/repos/asf/lucene/dev/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 964467
{code}

I generated the diff with svn, but did not "add with history" when i moved 
TopDocs* to PQTopDocs*, this allows the diff to apply cleanly with patch, but 
is not optimal for svn history management.

with svn i guess, it's technically better to preserve the history and svn 
merge, which can track file adds w/ history etc.
i track my local changes with git, which does that automatically, so if there 
is a "preferred" way to generate patches wrt to svn that can actually apply 
with patch i'll generate that way.

Or if there is a way to apply a history preserving patch with svn, i'd love to 
know what it is. And i can figure out how to jostle that diff into my git repo 
on my own.


> 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