Ok, SOLR 2 can be a from the ground up rewrite? That would make things much easier. Otherwise Noble you are correct the integration from my perspective is messy and there would be a lot of things that are currently in SOLR that are unnecessary.
On Fri, Sep 5, 2008 at 9:00 AM, Mark Miller <[EMAIL PROTECTED]> wrote: > Ocean integration should really be targeted at solr 2 I think, so API > compatibility shouldn't be a large barrier. > > Noble Paul (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/SOLR-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628624#action_12628624 >> ] >> Noble Paul commented on SOLR-567: >> --------------------------------- >> >> As a general approach , A pluggable SolrCore does not look like a very >> good idea. Too many components depend on too many methods on SolrCore. So >> ,you will have to support all/most of them to be compatible . >> >> Corrrect me if I am wrong. You may only wish to plugin a IndexSearcher and >> and IndexWriter. If we make the SolrIndexSearcher and SolrIndexWriter >> pluggable ,that can be easier >> >> >>> >>> SolrCore Pluggable >>> ------------------ >>> >>> Key: SOLR-567 >>> URL: https://issues.apache.org/jira/browse/SOLR-567 >>> Project: Solr >>> Issue Type: Improvement >>> Affects Versions: 1.3 >>> Reporter: Jason Rutherglen >>> Attachments: solr-567.patch, solr-567.patch >>> >>> >>> SolrCore needs to be an abstract class with the existing functionality in >>> a subclass. SolrIndexSearcher the same. It seems that most of the Searcher >>> methods in SolrIndexSearcher are not used. The new abstract class need only >>> have the methods used by the other Solr classes. This will allow other >>> indexing and search implementations to reuse the other parts of Solr. Any >>> other classes that have functionality specific to the Solr implementation of >>> indexing and replication such as SolrConfig can be made abstract. >>> >> >> > >
