<div dir="ltr">Thank you Thomas for your comments --<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 20, 2016 at 1:33 PM, Thomas Mäder <span dir="ltr"><<a href="mailto:tmader@redhat.com" target="_blank">tmader@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Hi Shoubik,</p><span class="gmail-">
<br>
<div class="gmail-m_-2924417475018983415moz-cite-prefix">On 10/20/2016 09:23 AM, Shoubhik Bose
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li>The ID search is currently only on workitems. ( But in
future it would be supported for other objects as well.
Example, Users,etc. )<br>
<br>
To search by ID --<br>
<br>
/api/search/q<b>=id:4324</b> <br>
This is going to look up the workitem table <b>only</b>.
<br>
</li>
</ol>
</div>
</div>
</blockquote>
<br>
</span><p>What is the reason we are not using the "filter" parameter on the
/api/workitems endpoint for searching? <br></p></div></blockquote><div><br></div><div>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.<br><br></div><div>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<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p>
</p>
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.<span class="gmail-"><br>
<br></span></div></blockquote><div><br><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li>To search by URL --<br>
<br>
/api/search/q<b>=url:<a href="http://demo.almighty.io/#/detail/71" target="_blank">http://demo.<wbr>almighty.io/#/detail/71</a></b>
<br>
</li>
</ol>
</div>
</div>
</blockquote></span>
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.<span class="gmail-"><br></span></div></blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li>Search by ID *AND* URL is not supported.<br>
If a q=xxyzz contains both URL and ID, we only pickup the
URL and discard the rest.<br>
<br>
Example.<br>
/api/search/q=<b>id:4324</b>+<b>url:<a href="http://demo.almighty.io/#/detail/71" target="_blank">http<wbr>://demo.almighty.io/#/detail/<wbr>71</a><br>
<br>
</b>is effectively<br>
<br>
<b> </b>/api/search/q=<b>url:<a href="http://demo.almighty.io/#/detail/71" target="_blank">http://demo.<wbr>almighty.io/#/detail/71</a><br>
</b></li>
</ol>
</div>
</div>
</blockquote></span>
I don't think we should ignore parameters. If the query is not in a
correct format, we should return an error.<span class="gmail-"><br></span></div></blockquote><div><br></div><div>Agreed. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li>Free text search is supported only on workitem title and
description<br>
<br>
/api/search/q:=<b>title:some title substring</b>+<b>description:some
description substring<br>
</b></li>
</ol>
</div>
</div>
</blockquote></span>
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.<span class="gmail-"><br></span></div></blockquote><div><br></div><div>Very good point.<br></div><div>Yes limiting and ranking would definitely be needed. Paging is planning for this sprint. <br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li>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.<br>
</li>
</ol>
</div>
</div>
</blockquote></span>
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.)<span class="gmail-"><br>
<blockquote type="cite">
<div dir="ltr">
<div>if the search query contains a mix of ID, URL ,
title,description :<br>
<ol>
<li>The order in which we are going to look for fields to
make a decision on the search is:<br>
<br>
1. URL<br>
2. ID <br>
3. title and description ( for free text search )<br>
</li>
</ol>
</div>
</div>
</blockquote></span>
What "decision" do you mean here? Are you thinking about ranking?<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></div></blockquote><div><br></div><div>No, this is not about ranking. By decision I mean .. "code it in such a way such that so and so happens by design" :)<br></div><div><br></div><div>If my URL contains<br><br></div><div>q=url:SOME_URL+id:32323+title:some_title+description:some_description<br><br></div><div>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<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-HOEnZb"><font color="#888888">
<br>
/Thomas<br>
<br>
<br>
</font></span></div>
</blockquote></div><br></div></div></div>