[
https://issues.apache.org/jira/browse/LUCENE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977764#action_12977764
]
Robert Muir commented on LUCENE-2837:
-------------------------------------
Hello, I think we should revisit branch_3x here. I'm not asking for a backport
but i think we should do some targeted javadoc+deprecations:
* I think we should deprecate Searcher, suggesting to use IndexSearcher
instead. Searcher->IndexSearcher is probably the only way
this change will affect 99% of users and so this fixes that case, as most users
make a simple change to their code.
* We could add some wordage to MultiSearcher, such as 'if you are making a MS
of IS you might want to consider MR instead'. This would
be nice since we are still going to have the lurking combine() bug, at least
people then know that MR is recommended.
* i think it would be nice to add something to contrib/remote so users expect
to change their code? Personally I think we should deprecate.
Deprecate doesn't mean there has to be a 1-1 replacement... sometimes we
re-think and it wasnt the best idea all along. But deprecation
helps alert anyone using it so they wont be surprised with 4.0
> 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
> Fix For: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
