lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3769) Simplify NRTManager
Date Fri, 10 Feb 2012 18:29:06 GMT


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:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message