incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <and...@digiverse.si>
Subject Re: Improved Search Architecture - Quick Search Box (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
Date Thu, 22 Nov 2012 14:20:34 GMT
> On a technical note, is there any reason to specify text~= for a general
text query? I would have
> thought that we could distinguish free text (as perhaps suggested below
in the examples below.)
Agreed and fixed the BEP accordingly.



>> Other nice to have features:
>>    - Did you mean...
>>    - Suggestions during typing
>>
> > The second is probably more useful than the former but these are
probably worth considering later
Definitely, I meant "nice to have features" as possible by really but low
priority.
IMHO, after the discussion, we should come with list of first priority
tickets and left "nice to have features" for later.

Regards, Andrej

>
On 22 November 2012 13:01, Gary Martin <gary.martin@wandisco.com> wrote:

> Hi Andrej,
>
> Thanks for this. There are plenty of good ideas here but I will go through
> it in parts creating different threads. Hope that is good for everyone.
>
> On 22/11/12 11:08, Andrej Golcov wrote:
>
>> Hi all,
>>
>> I've just added first draft of proposal for search improvements. So, let's
>> discuss it :)
>>
>> I suggest that we agree on functional requirements and then pass to
>> possible implementation.
>>
>> Regards, Andrej
>>
>>
>> On 22 November 2012 11:32, Apache Bloodhound <
>> bloodhound-dev@incubator.**apache.org<bloodhound-dev@incubator.apache.org>>
>> wrote:
>>
>>  Page "Proposals/BEP-0004" was added by andrej
>>> Content:
>>> -------8<------8<------8<-----**-8<------8<------8<------8<---**
>>> ---8<--------
>>>
>>> = BEP 4 : Improved search architecture #overview
>>>
>> [snipped]
>
>>
>>> === Quick search box
>>>
>>> Quick search box should be just frontend for adhoc query. For example, if
>>> user searches for “bla” string, user receives Search Result view with the
>>> following query:  text~=”bla”. User can refine query in Query Result
>>> view.
>>>
>> Quick search should probably maintain all the syntax that a query results
> view search box provides. The main reason for providing a different search
> box would be that you can construct a larger text query and keep it in
> view, which seems quite nice. It would also solve the current problem of
> attempting to refine the search in the quick search field resulting in the
> dropping of the filters (though this could be solved by adding the filters
> to the quick search query.)
>
> On a technical note, is there any reason to specify text~= for a general
> text query? I would have thought that we could distinguish free text (as
> perhaps suggested below in the examples below.)
>
>
>>> Search box should accept the following search types:
>>>    - free-text search: “bla”
>>>    - free-text + query: bla status!=closed
>>>    - query only: status!=closed
>>>
>>
> This looks good. At the moment the quick search requires
> "query:status!=closed" for the last of those and to include the free-text
> search you would need to query a whole set of fields to see if they contain
> the text. This is clearly not as quick and intuitive. Obviously, as soon as
> you bring field queries into the problem you are automatically focusing on
> resources that have that field available (possibly relaxed when there is an
> OR operator involved - think "bla OR status!=closed")
>
>>
>>> Other nice to have features:
>>>    - Did you mean...
>>>    - Suggestions during typing
>>>
>>
> The second is probably more useful than the former but these are probably
> worth considering later.
>
> Cheers,
>     Gary
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message