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

[Shoubhik Bose]

Thanks Max -
please find my comments inline.

On Thu, Oct 20, 2016 at 1:21 PM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

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

So the 'smart guess' would either be similar to regex matching and figuring
out what to actually search for -
ID / URL. Effectively this would mean adding support for a use case where
'no explicit key (url,id) was provided.

What the explicit key specification does is reduce the cost of figuring out
what to look for.
Example, in Github whenever we type #SOME_NUMBER , it digs up issues and
PRs. To simplify things on the backend, the explicit specification of key
would be helpful. So in ALM whenever someone puts #SOME_NUMBER ,the UI
fires an Ajax request with the q=id:3235 , thus reduce the cost and
complexity of completing the search.

Same applies for workitem linking by URL where the search needs to be
explicitly by URL.


> 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.
>
> Good idea. Agreed.


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

I meant *system.title *, sorry for the confusion :)


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

Actually, some stuff here is mutually exclusive. Just like #3 , this should
return an empty result because it would make no sense for URL and ID to
co-exist in the search query.


> /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/d2f4cbef/attachment.htm>