lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4355) improve AtomicReader sugar apis
Date Tue, 04 Sep 2012 13:03:07 GMT


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.

* docFreq(Term) -> forwards to docFreq(String, BytesRef)
* docFreq(String, BytesRef) -> (abstract: this can be seen as a sugar API)

* 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:
>             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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message