I should probably only reply with a bit more knowledge of how search
fits together but here goes...
In the simplest form the choice could be implemented by only allowing
one of the search backend components to be active. However, it sounds
like it has already been implemented in such a way that both are
allowed to be active at the same time. As such someone (perhaps you
but it could be worth focussing on more important issues) might
eventually have to work out how the administrator can set which of the
active backends that is used on the default search path. Adding a new
admin panel for search settings might be useful for that particularly
if there are multiple settings are worth exposing. Until this is
fixed, there may be some confusion about which backend is providing
the service.
Also, I assume that when multiple search backend components are
active, each will receive index updates and so extra work is required
on the server to process this.
You can probably ignore my comment about performance for the purposes
of your project (unless it was a part of your proposal), though it
would be interesting to know how the backends compare in response
times, memory usage and the quality of results in a relatively fair
way (if there is a good way of comparing result quality). It is
probably better to look at doing this with tools external to the
available backends. It might also be argued that it would be more fair
to measure response times on the same data and platform but without
the extra infrastructure that any particular backend requires.
You are obviously correct that users can't be expected to compute
performance of their own system without trying it out. However, it is
probably fair to say that users will be happy enough if searches
return relevant enough results in a reasonable time. As a consequence
it may be that people stick with whatever is default until they find a
need to change.
I am vaguely expecting that Solr will be worth installing for larger
installations and perhaps particularly when the Solr can be put on a
different server. It really is just an uninformed guess though!
Cheers,
Gary
On 17/06/2014, Antonia Horincar <[email protected]> wrote:
> 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
>>
