You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2013/07/04 17:01:54 UTC

[jira] [Comment Edited] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances

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