lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (LUCENE-2837) Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS into IndexSearcher
Date Wed, 05 Jan 2011 19:32:47 GMT


Yonik Seeley commented on LUCENE-2837:

The multithreaded stuff feels like it should be in a subclass of IndexSearcher.
But barring that, perhaps make it so that the subSearcher array is only populated if there
is an executor passed in (to try and keep IndexSearcher as light weight as possible)?

> Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS into IndexSearcher
> -----------------------------------------------------------------------------------------------
>                 Key: LUCENE-2837
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 3.1, 4.0
>         Attachments: LUCENE-2837.patch, LUCENE-2837.patch
> We've discussed cleaning up our *Searcher stack for some time... I
> think we should try to do this before releasing 4.0.
> So I'm attaching an initial patch which:
>   * Removes Searcher, Searchable, absorbing all their methods into IndexSearcher
>   * Removes contrib/remote
>   * Removes MultiSearcher
>   * Absorbs ParallelMultiSearcher into IndexSearcher (ie you can now
>     pass useThreads=true, or a custom ES to the ctor)
> The patch is rough -- I just ripped stuff out, did search/replace to
> IndexSearcher, etc.  EG nothing is directly testing using threads with
> IndexSearcher, but before committing I think we should add a
> newSearcher to LuceneTestCase, which randomly chooses whether the
> searcher uses threads, and cutover tests to use this instead of making
> their own IndexSearcher.
> I think MultiSearcher has a useful purpose, but as it is today it's
> too low-level, eg it shouldn't be involved in rewriting queries: the
> Query.combine method is scary.  Maybe in its place we make a higher
> level class, with limited API, that's able to federate search across
> multiple IndexSearchers?  It'd also be able to optionally use thread
> per IndexSearcher.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message