lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2837) Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS into IndexSearcher
Date Wed, 05 Jan 2011 22:58:50 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978021#action_12978021
] 

Michael McCandless commented on LUCENE-2837:
--------------------------------------------

bq. How about this little patch to avoid creation of IndexSearcher per-segment if not needed?

Looks great!

> Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS into IndexSearcher
> -----------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2837
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2837
>             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, 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message