[
https://issues.apache.org/jira/browse/LUCENE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559069#comment-13559069
]
Robert Muir commented on LUCENE-4524:
-------------------------------------
I agree its a great! change, but perhaps this should be committed to the 2878
branch for now to see how it plays in practice?
Otherwise I have a few concerns about committing to trunk (none of which have
to do with the particular patch, just problems in general)
* Scorer.java will be strange, as it will have various methods like
nextPosition(), getPayload(), that do not work. Of course this API would be
fantastic and make total sense if this was the api for LUCENE-2878, but in the
meantime it would be odd and confusing.
* I'm not sure how i feel about nextPosition(), getPayload(), start/endOffset()
all going from abstract to 'default nonfunctioning impl'. It might be the right
tradeoff, but i definitely liked them better as abstract. Its hard to tell
without seeing how the Scorer integration would ultimately play out.
* with DocsEnum and DocsAndPositionsEnum merged, the possibility of reuse bugs
in various postings implementations is increased. We should review our own code
here...
> 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.2, 5.0
>
> Attachments: 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 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
