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

[Max Rydahl Andersen]

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

Sure, if user typed #123 you know it is an ID to look for, but if you 
then
see in GitHub what it does is that it do a "123.*" search on the id with
what looks like a last visited ranking. Thus it is not exactly a perfect 
match
search.

For our first version explicit match is fine IMO, just that for the 
final form
something more flexible than exact match is needed.

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

Thus this is fine for internal searches - I reckon once we need to 
expose it to users
we'll not want to require users to prefix everything with "system" nor 
having to
distinguish too much between system and UI visible names.

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

Why not ?

id:123 http://demo.almighty.io/#/detail/123

would result in one item: http://demo.almighty.io/#/detail/123

/max
http://about.me/maxandersen