[
https://issues.apache.org/jira/browse/LUCENE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121140#comment-13121140
]
Simon Willnauer commented on LUCENE-3488:
-----------------------------------------
bq. What you suggest only makes sense at a high level if you wave your hands
around alot. If you get down to the details, it makes little sense.
i am not saying we should but if we take this as a basis we should have never
started with flex, DWPT etc. Stuff like this can only improve the quality of
the product, make it lean and easier to maintain.
> Factor out SearcherManager from NRTManager
> ------------------------------------------
>
> Key: LUCENE-3488
> URL: https://issues.apache.org/jira/browse/LUCENE-3488
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 3.5, 4.0
> Reporter: Simon Willnauer
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3488.patch
>
>
> Currently we have NRTManager and SearcherManager while NRTManager contains a
> big piece of the code that is already in SearcherManager. Users are kind of
> forced to use NRTManager if they want to have SearcherManager goodness with
> NRT. The integration into NRTManager also forces you to maintain two
> instances even if you know you always want deletes. To me NRTManager tries to
> do more than necessary and mixes lots of responsibilities ie. handling
> searchers and handling indexing generations. NRTManager should use a
> SearcherManager by aggregation rather than duplicate a lot of logic.
> SearcherManager should have a NRT and Directory based implementation users
> can simply choose from.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]
