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

[Aslak Knutsen]

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.


>
>    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.


>
>    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"


>
>    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


>
>    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-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161020/3c276a7a/attachment.htm>