[
https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13700114#comment-13700114
]
Uwe Schindler commented on LUCENE-5092:
---------------------------------------
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
