[ 
https://issues.apache.org/jira/browse/LUCENE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated LUCENE-4524:
----------------------------------
    Attachment: LUCENE-4524.patch

This patch merges the old DocsEnum and DocsAndPositionsEnum into a new 
PostingsEnum class (which is basically the old DaPE class), with DocsEnum 
extending it as a convenience class returning empty values for positions, 
offsets and payloads.

TermsEnum.docs() methods are renamed to TermsEnum.postings().

The old docs() and docsAndPositions() methods can be added back to keep 
backwards compatibility.

Next up: some basic re-use tests.  I think we should be able to assert that 
things *aren't* reused when we have different postings requested for all 
postings formats, and check specific cases for those formats where re-use is 
actually implemented.

> Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum
> ---------------------------------------------------------
>
>                 Key: LUCENE-4524
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4524
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/codecs, core/index, core/search
>    Affects Versions: 4.0
>            Reporter: Simon Willnauer
>             Fix For: 4.9, Trunk
>
>         Attachments: LUCENE-4524.patch, LUCENE-4524.patch, LUCENE-4524.patch, 
> LUCENE-4524.patch
>
>
> spinnoff from http://www.gossamer-threads.com/lists/lucene/java-dev/172261
> {noformat}
> hey folks, 
> I have spend a hell lot of time on the positions branch to make 
> positions and offsets working on all queries if needed. The one thing 
> that bugged me the most is the distinction between DocsEnum and 
> DocsAndPositionsEnum. Really when you look at it closer DocsEnum is a 
> DocsAndFreqsEnum and if we omit Freqs we should return a DocIdSetIter. 
> Same is true for 
> DocsAndPostionsAndPayloadsAndOffsets*YourFancyFeatureHere*Enum. I 
> don't really see the benefits from this. We should rather make the 
> interface simple and call it something like PostingsEnum where you 
> have to specify flags on the TermsIterator and if we can't provide the 
> sufficient enum we throw an exception? 
> I just want to bring up the idea here since it might simplify a lot 
> for users as well for us when improving our positions / offset etc. 
> support. 
> thoughts? Ideas? 
> simon 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to