[
https://issues.apache.org/jira/browse/LUCENE-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205609#comment-13205609
]
Michael McCandless commented on LUCENE-3769:
--------------------------------------------
bq. Yet, I don't think NRTManager should expose IndexSearcher directly.
Hmm, but the example you raised will be addressed by LUCENE-3761, right? Ie at
that point, both SM and NRTM are ThingyManager<IndexSearcher>?
I don't like the extra indirection (you get an SM from NRTM) because now you
have two linked instances. For example, it opens up the risk that the app will
(incorrectly) call SM.maybeReopen instead of NRTM.maybeReopen. I think having
the one manager to work with is less dangerous...
> Simplify NRTManager
> -------------------
>
> Key: LUCENE-3769
> URL: https://issues.apache.org/jira/browse/LUCENE-3769
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3769.patch
>
>
> NRTManager is hairy now, because the applyDeletes is separately passed
> to ctor, passed to maybeReopen, passed to getSearcherManager, etc.
> I think, instead, you should pass it only to the ctor, and if you have
> some cases needing deletes and others not then you can make two
> NRTManagers. This should be no less efficient than we have today,
> just simpler.
> I think it will also enable NRTManager to subclass ThingyManager
> (LUCENE-3761).
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
