[
https://issues.apache.org/jira/browse/LUCENE-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597069#comment-13597069
]
Robert Muir commented on LUCENE-4694:
-------------------------------------
I opened this issue because of stuff I see on the mailing lists and on the
internet.
I dont care which way we fix it, but the complete fix cannot simply be removal
of methods.
If we want to force users to use these things per-segment, then the API and doc
must be fixed
so that its easy and natural to do so.
For example IR has nothing in its javadocs about how to work the leaves per
segment. its also
confusing that leaves() returns AtomicReaderContext. I'm confused why we have
to return such a class
instead of AtomicReaders directly from leaves. Someone going per-segment doesnt
need this to know docbases right?
{code}
int docBase - 0;
for (AtomicReader ar : ir.leaves()) {
// something
docBase += ar.maxDoc();
}
{code}
> Add back IndexReader.fields() -> Multi*, or discourage term vectors in some
> better way
> --------------------------------------------------------------------------------------
>
> Key: LUCENE-4694
> URL: https://issues.apache.org/jira/browse/LUCENE-4694
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-4694.patch
>
>
> Users can easily get term vectors from any indexreader, but not postings
> lists. this encourages them to do really slow things: like pulling term
> vectors for every single document.
> this is really really so much worse than going through multifields or
> whatever.
--
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]
