[
https://issues.apache.org/jira/browse/LUCENE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754835#comment-13754835
]
Robert Muir commented on LUCENE-5123:
-------------------------------------
Maybe we should:
# move write() from PostingsFormat to FieldsConsumer
# make the "push" api a subclass of FieldsConsumer that has a final
implementation of write() and exposes the abstract api it has today (e.g.
addField)
or we can keep the names the same and have the new one be "underneath"
FieldsConsumer (e.g. RawFieldsConsumer).
But I am not sure we should focus on nuking the old api or even cutting over
impls that dont "need" the visitor api, since the existing api works pretty well
for a lot of implementations and if you dont need to do fancy stuff it might be
easier and less error-prone.
> invert the codec postings API
> -----------------------------
>
> Key: LUCENE-5123
> URL: https://issues.apache.org/jira/browse/LUCENE-5123
> Project: Lucene - Core
> Issue Type: Wish
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Attachments: LUCENE-5123.patch, LUCENE-5123.patch, LUCENE-5123.patch
>
>
> Currently FieldsConsumer/PostingsConsumer/etc is a "push" oriented api, e.g.
> FreqProxTermsWriter streams the postings at flush, and the default merge()
> takes the incoming codec api and filters out deleted docs and "pushes" via
> same api (but that can be overridden).
> It could be cleaner if we allowed for a "pull" model instead (like
> DocValues). For example, maybe FreqProxTermsWriter could expose a Terms of
> itself and just passed this to the codec consumer.
> This would give the codec more flexibility to e.g. do multiple passes if it
> wanted to do things like encode high-frequency terms more efficiently with a
> bitset-like encoding or other things...
> A codec can try to do things like this to some extent today, but its very
> difficult (look at buffering in Pulsing). We made this change with DV and it
> made a lot of interesting optimizations easy to implement...
--
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]
