Thank you for all the replies. Yes, I guess you are right, only the admin should be able to choose which search platform to be used. The Solr plugin doesn’t implement IQueryParser, but I’ll modify it so that it implements it, and therefore it should work if the user modifies the trac.ini file accordingly. Should I also modify the Admin/General/Plugin section in the web UI so that the admin can disable Whoosh and enable Solr, and vice versa? If so, which files should be modified?
Also, Gary, you mentioned comparing the performance of the two search platforms. Could you please describe exactly what you mean by performance? Are you referring to info such as average response time? If this is the case, how should the admin observe the performance differences between the two platforms? And what if the admin never switches to Whoosh for example, how should the performance for Whoosh be computed then? Thanks, Antonia On 16 June 2014 at 20:58:00, Gary Martin ([email protected]) wrote: Yes, this shouldn't be a per user choice. Equally I don't think it is worth providing a different search path, at least by default anyway. There might be an interest in being able to compare performance and results of course but, as Mat says, non-admin users should not have any need to worry whether the search backend is available or which choice is better for them. Cheers, Gary On 16 June 2014 16:11, Mat Booth <[email protected]> wrote: > > ----- Original Message ----- > > From: "Antonia Horincar" <[email protected]> > > To: [email protected] > > Sent: Monday, 16 June, 2014 3:32:39 PM > > Subject: [GSoC COMDEV-108] Integrating the Solr plugin with BH interface > and a question regarding ISearchBackend > > method > > > > 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? > > > > > Wouldn't this sort of option normally be an administrative decision? I.e., > have an option somewhere in the admin section to select which search > provider to use? > > I don't like the idea of forcing the user make this decision because they > are likely not even going to know what Whoosh or Solr is, let alone the > implications of the choice they make. > > Regards, > Mat Booth > Software Engineer, Red Hat Eclipse Team > > > > 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 > -- Gary Martin Lead Open Source Developer | WANdisco <http://www.wandisco.com/>
