[
https://issues.apache.org/jira/browse/LUCENE-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447666#comment-13447666
]
Robert Muir commented on LUCENE-4355:
-------------------------------------
I agree, this was mainly to start discussion about what sugar apis we should
have.
Currently its very inconsistent.
IndexReader:
* docFreq(Term) -> forwards to docFreq(String, BytesRef)
* docFreq(String, BytesRef) -> (abstract: this can be seen as a sugar API)
AtomicReader:
* totalTermFreq(String, BytesRef) -> strange to be treated differently than
docFreq, sugar to seekExact+totalTermFreq
* terms(String) -> note that in 3.x terms() and terms(Term) are different and
go to TermsEnum (unpositioned and positioned)
* termDocsEnum(Bits, String, BytesRef) -> the Bits should be implicit in the
reader. if you want your own bits use flex apis?
* termDocsEnum(Bits, String, BytesRef, int) -> flags seems too expert
* termPositionsEnum(Bits, String, BytesRef)
* termPositionsEnum(Bits, String, BytesRef, int)
So we should also discuss whether its useful to use Term at the indexReader
level. If we are going to have sugar
for docFreq(Term) then we should do this elsewhere too? Term is somewhat nice
because it means users don't have
to deal with BytesRef etc.
I wonder if totalTermFreq sugar is necessary here too, if we instead make it
easy for you to get a positioned termsenum for
a specific term (you could just call it yourself then).
We should also think about the names termDocsEnum/termPositionsEnum. in 3.x
these were termDocs() and termPositions(),
and could take Term.
The only thing I feel pretty strongly about is that I think passing a custom
Bits is too expert for these sugar APIs,
as its something implicit from the Reader itself.
> improve AtomicReader sugar apis
> -------------------------------
>
> Key: LUCENE-4355
> URL: https://issues.apache.org/jira/browse/LUCENE-4355
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Robert Muir
>
> I thought about this after looking @ LUCENE-4353:
> AtomicReader has some sugar APIs that are over top of the flex apis (Fields,
> Terms, ...). But these might be a little trappy/confusing compared to 3.x.
> # I dont think we need AtomicReader.termDocsEnum(Bits, ...) and
> .termPositionsEnum(Bits, ...). I also don't think we need variants that take
> flags here. We should simplify these to be less trappy. I think we only need
> (String, BytesRef) here.
> # This means you need to use the flex apis for more expert usage: but we make
> this a bit too hard since we only let you get a Terms (which you must null
> check, then call .iterator() on, then seekExact, ...). I think it could help
> if we balanced this out by adding some sugar like AtomicReader.termsEnum? 3.x
> had a method that let you get a 'positioned termsenum'.
--
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]
