[
https://issues.apache.org/jira/browse/LUCENE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395840#comment-13395840
]
Uwe Schindler edited comment on LUCENE-4152 at 6/18/12 12:02 PM:
-----------------------------------------------------------------
bq. They also have tricky semantics (e.g. returning null).
No longer since January's refactoring, leaves() returns always something !=
null. And getSeqSubReaders is only available on CompositeReaders, which always
have subReaders. See the other issue LUCENE-3866 where I did some more
refactoring to make all this easier.
In general I agree with that, as leaves() and children()/subs() would then just
be a shortcut to getTopReaderContext()'s methods (leaves(), children() - both
are Iterable, no need to change anything) (I would rename that one to
as[Top]Context()).
Returning plain subReaders without Contexts is not really useful, as all of
Lucene's Query logic uses AtomicReaderContext, so leaves() on IndexReader
returning the same as getTopReaderContext().leaves() is the way to go. This
method can be added as final "easy-use method". I hope you look at my other
patch @ LUCENE-3866, because it shows how simple the code is now without
ReaderUtil.Gather.
Additionally, as noted in LUCENE-3866, getSequentialSubReaders() in
CompositeReader should be made protected, user code does not need to use it.
It's solely there for building the reader hierarchy, later available using
IRC.leaves() and IRC.children(). Currently this method is only used by tests
anymore (which can be rewritten). In CompositeReader, getSequentialSubReaders()
should just be the protected abstract way for the API on top to get the inner
structure, but not for the outside.
was (Author: thetaphi):
bq. They also have tricky semantics (e.g. returning null).
No longer since January's refactoring, leaves() returns always something !=
null. And getSeqSubReaders is only available on CompositeReaders, which always
have subReaders. See the other issue LUCENE-3866 where I did some more
refactoring to make all this easier.
In general I agree with that, as leaves() and children()/subs() would then just
be a shortcut to getTopReaderContext()'s methods (leaves(), children() - both
are Iterable, no need to change anything) (I would rename that one to
as[Top]Context()).
Returning plain subReaders without Contexts is not really useful, as all of
Lucene's Query logic uses AtomicReaderContext, so leaves() on IndexReader
returning the same as getTopReaderContext().leaves() is the way to go. This
method can be added as final "easy-use method". I hope you look at my other
patch @ LUCENE-3866, because it shows how simple the code is now without
ReaderUtil.Gather.
> add one-syllable method to IndexReader enumerate subreaders
> -----------------------------------------------------------
>
> Key: LUCENE-4152
> URL: https://issues.apache.org/jira/browse/LUCENE-4152
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Robert Muir
> Priority: Blocker
> Fix For: 4.0
>
>
> Description is exactly as written.
> getSequentialSubReaders/getTopLevelReaderContext, these method names are way
> too long/unuseable. They also have tricky semantics (e.g. returning null).
> In lucene 4, people cannot just use any indexreader and get a merged view. So
> we need to make this stuff easy on them:
> * single-syllable method name (leaves(), subs(), i will think on this)
> * supports enhanced for-loop (no returning null or anything like that)
> * on indexreader (not atomic or composite, plain old indexreader)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
