[almighty] How would the 'search' URLs look like for the ALM Search service ?

[Max Rydahl Andersen]

Hi Shoubhhik,


> Hi folks,
>
> Wanted to discuss how the /api/search URL(s) would look like.
>
> To set the scope of the discussion right, I must mention that in this
> sprint we are working on supporting search on ID , URL and full text ( 
> for
> title and description only ) of a workitem.

>    1. The ID search is currently only on workitems. ( But in future it
>    would be supported for other objects as well. Example, Users,etc. )
>
>    To search by ID --
>
>    /api/search/q*=id:4324*
>    This is going to look up the workitem table *only*.
>
>    2.
>    To search by URL --
>
>    /api/search/q*=url:http://demo.almighty.io/#/detail/71
>    <http://demo.almighty.io/#/detail/71>*

This api seems good for when you explicitly know what key you want to 
search for.

I'm wondering if in the case for the autocomplete/type-ahead context if 
it would not make sense to a have a "fuzzy" or smart search that will 
simply do a smart guess of what you are trying to search for. Even do 
all three searched and sort them by probability ?

Examples:

`/api/search/q=4324` would return first the items with that exact id and 
secondly any issues that has text match on that query ?

`/api/search/q=http://d.a.io/#/71` would return first the items with 
that exact url id and secondly any issues that has text match (and in 
future dependency) on that query ?


>    3.
>    Search by ID *AND* URL is not supported.
>    If a q=xxyzz  contains both URL and ID, we only pickup the URL and
>    discard the rest.
>
>    Example.
>    /api/search/q=*id:4324*+
>
> *url:http://demo.almighty.io/#/detail/71
>    <http://demo.almighty.io/#/detail/71> *is effectively
>
>    /api/search/q=
>
> *url:http://demo.almighty.io/#/detail/71
>    <http://demo.almighty.io/#/detail/71> *

With respect to your #3 I would consider that an empty result since for 
search terms it is normal to have an explicit `AND` between them. Thus 
`q=id:4324 url:http://demo.almighty.io/#/detail/71` means it needs to 
match both terms which by definition is impossible - thus empty result.

>    4.
>    Free text search is supported only on workitem title and 
> description
>
>    /api/search/q:=*title:some title substring*+
> *description:some description substring *

Again, great if we can search on specific fields, but I would think we 
would want a higher level search that is "smart" about searching across 
various fields rather than explicit.

With respect to what field names we use - are these fields the "system" 
names or the field names that are on the type ? I reckon in the long run 
we need both ?

> 5.
>    The delimiter for multiple clauses ( we shall support "AND" now ) 
> will
>    be "+" . ( inspired from Github ) as already used above. We need to
>    consider situations where the string itself contains a "+" by 
> escaping them
>    properly.

+1

>    6. if the search query contains a mix of ID, URL , 
> title,description :
>    The order in which we are going to look for fields to make a 
> decision on
>    the search is:
>
>    1. URL
>    2. ID
>    3. title and description ( for free text search )

explicit AND is my expectation. No magic ordering in this.

/max

>    Let me know your thoughts :)
>
>    -
>    Shoubhik




/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161020/b8926c25/attachment.htm>