[jira] Resolved: (LUCENE-2837) Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS into IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-2837. Resolution: Fixed 3rd time's a charm? 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Resolved: (LUCENE-2837) Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS into IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-2837. Resolution: Fixed 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
[jira] Resolved: (LUCENE-2837) Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS into IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-2837. Resolution: Fixed 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 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
