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

[Shoubhik Bose]

Thanks Aslak --
Please find my comments inline:

On Thu, Oct 20, 2016 at 3:14 PM, Aslak Knutsen <aslak at redhat.com> wrote:

>
>
> On Thu, Oct 20, 2016 at 9:23 AM, Shoubhik Bose <shbose at redhat.com> wrote:
>
>> 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*.
>>
>>
>>
> I would remove the need for "id:". It's fine to support a direct field
> search, but it shouldn't be required.
>
> Any object can have a "id", so it can't 'just' look in workitem table,
> even tho that is the only supported for now.
>


If I'm doing an ID lookup, should I be doing a /api/search/q=20596  ?


>
>
>>
>>    1.
>>    2.
>>    To search by URL --
>>
>>    /api/search/q*=url:http://demo.almighty.io/#/detail/71
>>    <http://demo.almighty.io/#/detail/71>*
>>
>>
>>
> I would remove the need for "url:". It's fine to support a direct field
> search, but it shouldn't be required.
>
>

If I'm doing a URL lookup, should I be doing a /api/search/q=*http://demo
<http://demo>.almighty.io/#/detail/71 <http://almighty.io/#/detail/71>*    ?


>
>>    1.
>>
>>    2.
>>    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> *
>>
>> Perosnally I wouldn't ignore any fields, I would rather return no result.
> There is no 'Object' with id 4324 and URL x.
>
> e.g. this JPQL is perfectly legal, it just doesn't return anything:
>
> issue = "ARQ-100" AND issue = "ARQ-200"
>
>

Got it , makes sense.


>
>>    1.
>>    2.
>>    Free text search is supported only on workitem title and description
>>
>>    /api/search/q:=*title:some title substring*+*description:some
>>    description substring*
>>
>>
> I would remove the need for "title:" and "description:". It's fine to
> support a direct field search, but it shouldn't be required.
>
> I would expect "some title substring some description substring" to end up
> as a search like:
>
> *some* AND *title* AND *substring* AND *description" -> search across all
> available fields for all objects
>
>


If I'm doing a search as

/api/search/q=20596 my_title my_description http://some_url
( here the spaces are AND )

As per your below comment on delimiters,

We get the following tokens:

1. 20596
2. my_title
3. my_description
4. http://some_url

How would you recommend the search to go on from here?




>>    1.
>>
>> 2.
>>    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.
>>
>>
>> I think tokenized on 'space' and use that as AND would work for now.
>
>
>>
>>    1.
>>    2. 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 )
>>
>>
>>
>>
>>    1.
>>
>>    Let me know your thoughts :)
>>
>>
>>    -
>>    Shoubhik
>>
>>
>>
>>
>
> -aslak-
>


---
Shoubhik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161020/aae9036b/attachment.htm>