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

Uwe Schindler edited comment on LUCENE-5092 at 7/4/13 3:00 PM:
---------------------------------------------------------------

There are 2 possibilities:
- Let the iterator implement an additional interface that exposes prev() or how 
we call that method. The code when then use instanceof to check if backwards is 
supported on the iterator
- Do it similar to random access bits() on the DocIdSet. In that case a 
consumer could ask the DocIdSet for a backwardsIterator(), which returns null 
if not existent

We should never add an additional method to DocIdSetIterator, because then we 
would also have Scorers or DocsEnum optionally supporting going backwards! So 
please use an interface as marker + method definition!!!

I would prefer the first possibility, especially if you need to go both 
backwards and forwards on the same iterator instance.
                
      was (Author: thetaphi):
    There are 2 possibilities:
- Let the iterator implement an additional interface that exposes prev() or how 
we call that method. The code when then use instanceof to check if backwards is 
supported on the iterator
- Do it similar to random access bits() on the DocIdSet. In that case a 
consumer could ask the DocIdSet for a backwardsIterator(), which returns null 
if not existent

I would prefer the first possibility, especially if you need to go both 
backwards and forwards on the same iterator instance.
                  
> join: don't expect all filters to be FixedBitSet instances
> ----------------------------------------------------------
>
>                 Key: LUCENE-5092
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5092
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/join
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>            Priority: Minor
>
> The join module throws exceptions when the parents filter isn't a 
> FixedBitSet. The reason is that the join module relies on prevSetBit to find 
> the first child document given a parent ID.
> As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by 
> exposing methods in the iterators to iterate backwards. When the join modules 
> gets an iterator which isn't able to iterate backwards, it would just need to 
> dump its content into another DocIdSet that supports backward iteration, 
> FixedBitSet for example.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to