[
https://issues.apache.org/jira/browse/LUCENE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14293888#comment-14293888
]
Alan Woodward commented on LUCENE-4524:
---------------------------------------
In fact postings() turns out to be unnecessary, I just needed to fix
MappingMultiDocsEnum to check for nulls properly. The API seems to work OK,
actually, in that it works as before if you pass DocsEnum.FLAG_NONE or
DocsEnum.FLAG_FREQ, and works as docsAndPositions() did before if you pass
anything higher.
We should even be able to keep the API backwards-compatible if we rename the
merged enum to PostingsEnum (as the issue title suggests), and then have
deprecated DocsEnum and DocsAndPositionsEnum classes that extend it.
I'm going to add some more testing around re-use first.
> 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
>
>
> 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]
