Thanks for clearing that up. I understand the design decision behind
not using Iterable now.
Tricia
Yonik Seeley wrote:
On Thu, Mar 20, 2008 at 4:58 PM, Tricia Williams
<[EMAIL PROTECTED]> wrote:
Is your advice not to use DocSet, or not to use Iterable?
Not to use Iterable for a DocSet of any size, since the standard
iterator methods only deal in objects.
See the DocIterator interface... it's like a normal iterator but adds
nextDoc() that returns an int instead of an Integer.
-Yonik
If there is a
better way to put this information (payloads from tokens matching
queries) back together I'd love to hear it.
Thanks,
Tricia
Yonik Seeley wrote:
> I guess there's no reason for DocSet not to implement Iterable.
> I wouldn't use it myself for most things... boxing each integer in a
> big set is a nice waste of CPU.
>
> -Yonik
>
> On Thu, Mar 20, 2008 at 3:48 PM, Tricia Williams
> <[EMAIL PROTECTED]> wrote:
>
>> In my custom search component I'm using the DocSet
>> (http://lucene.apache.org/solr/api/org/apache/solr/search/DocSet.html)
>> supplied by a ResponseBuilder to iterate over TermPositions matched by
>> the users query and output the payload at each position.
>>
>> If DocSet implemented the Iterable interface
>> (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Iterable.html) I
>> would be able to do something like:
>>
>> TermPositions tp = searcher.getReader().termPositions( new Term(
fieldName, term.text() ) );
>>
>> for( int docId : docs ) {
>> tp.skipTo( docId );
>> //gather payloads from this document
>>
>> }
>>
>>
>> rather than have to monkey around with the DocIterator. Is this worth
>> opening an issue and writing a patch? Granted this is pretty trivial.
>> Or maybe I'm not seeing the easier way.
>>
>> Tricia
>>
>>
>
>
