[
https://issues.apache.org/jira/browse/LUCENE-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4355:
--------------------------------
Attachment: LUCENE-4355.patch
here's an incomplete patch just looking at IR.docFreq: found a few wierd things
looking around.
I think fixing all these sugar APIs is going to be pretty major and a lot of
work.
In general I think we can accomplish this issue in a backwards-compatible way
later: sure it will mean we have deprecations but I think this is better than
rushing stuff in.
> 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
> Attachments: LUCENE-4355.patch
>
>
> 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]
