I forgot to mention something, there is also the possibility of searching via Solr on a different path than the one used for Whoosh, e.g. base_url/main/product/product_prefix/solr_query, which eases the task of integrating the interface with the solr backend. However, this would mean that the user would have to access different URL’s for querying on Solr and Whoosh.
On 16 June 2014 at 15:32:56, Antonia Horincar ([email protected]) wrote: Hi, I would like to integrate what I’ve done so far for the Solr plugin with the existing interface for searching in BH. How should a user be able to choose between searching with Solr and searching with Whoosh? Should there simply be a button or a checkbox for choosing their preference? Also, what do you think would be the best approach for modifying the process_request method in bhsearch.web_ui.BloodhoundSearchModule (so that it initialises a SolrModel object if the user has chosen to use Solr, rather than a BloodhoundSearchApi object)? I know that all these would mean modifying some of the files in bhsearch, and therefore not having the bhsolr plugin as a completely separate unit, but I don’t see how can I obtain the wanted results without making these changes. Also, could you explain to me how the method start_operation() (from bhsearch.whoosh_backend.WhooshBackend) is used in the search plugin? From what I see, it is used for creating an asynchronous writer for Whoosh, which basically means that it adds and commits documents to the index. I’m not sure if I’m right here, this is just what I understood from reading about AsyncWriters in Whoosh. Is this correct? The reason I’m asking this is because some of the ISearchBackend methods take operation_context as parameter (which, in the bhsearch.api.BloodhoundSearchApi class, is obtained by calling the start_operation() method) , and I don’t know how should I deal with this in the Solr plugin. Best, Antonia
