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

[Shoubhik Bose]

Thank you Thomas for your comments --

On Thu, Oct 20, 2016 at 1:33 PM, Thomas Mäder <tmader at redhat.com> wrote:

> Hi Shoubik,
>
> On 10/20/2016 09:23 AM, Shoubhik Bose wrote:
>
>
>    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*.
>
>
> What is the reason we are not using the "filter" parameter on the
> /api/workitems endpoint for searching?
>

The search is planned to be expanded outside workitems as well in future.
However I agree that given our current scope of supporting search on
workitems only, the "list" action on workitems actually does a good job of
searching the work item field values.

I was wondering how to re-use that, but as I said we need to have a
separate /api/search anyway since this is not going to be restricted to
workitems only, and search would include users,etc. in future


> What are we searching for here? A prefix? A substring? If it's a search
> for the full id, we can just go to /api/workitems/4324. No need to search.
>
>

We need to have a separate /api/search since this is not going to be
restricted to workitems only, and search would include users,etc. in future.


>
>    1. To search by URL --
>
>    /api/search/q*=url:http://demo.almighty.io/#/detail/71
>    <http://demo.almighty.io/#/detail/71>*
>
> The work item service has no idea how to parse front end URL's. The front
> end needs to extract the work item id from this and use that for linking.
>

Good catch Thomas. Yes, the front-end doing that would be a better idea
else there would need to be some harcoding of the front-end URL patterns in
core code.


>
>
>    1. 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> *
>
> I don't think we should ignore parameters. If the query is not in a
> correct format, we should return an error.
>

Agreed.

>
>    1. Free text search is supported only on workitem title and description
>
>    /api/search/q:=*title:some title substring*+
> *description:some description substring *
>
> What does "free text search" mean? where title like "%some%" or title like
> "%title%" or something else (like a google search)? If we do something like
> a google search, we'll need to think about ranking and limiting the number
> of results.
>

Very good point.
Yes limiting and ranking would definitely be needed.  Paging is planning
for this sprint.
Do you think we need to have ranking/limiting for this in this sprint ? I
was wondering that this is implementation detail we can always improve on ,
once a basic search functionality is in place.


>
>    1. 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.
>
> As these are url parameters, we'll also need to delimit them somehow.
> Also, we don't only have text fields, how are we going to extend the format
> to other operators (<, >, etc.)
>
> if the search query contains a mix of ID, URL , title,description :
>
>    1. 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 )
>
> What "decision" do you mean here? Are you thinking about ranking?
>

No, this is not about ranking. By decision I mean .. "code it in such a way
such that so and so happens by design" :)

If my URL contains

q=url:SOME_URL+id:32323+title:some_title+description:some_description

Some stuff ( url , id ) here is clearly mutually exclusive and the results
could either be an empty set or error ( as you proposed above ). However,
if we choose to still show any result we would design our system in away
that rejects  either of url , id or free text stuff and considers any one
of them


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