Hi, > I would like to see others comment on the mockup for the query builder. Consistency with other > views suggest that there may be space on the right hand side, replacing the activity area - I > assume that we will not be displying activity on any search/query screen. +1
> Saved/stored queries have been discussed in the mailing list before a few times so I think this is > probably an expectation beyond the ability to put a search macro on a wiki page. I think that this > should probably be considered separately of this solution but we should make sure that such > stored queries support any implementation that arises from this. Let's consider saved/stored queries as postponed feature and concentrate on core changes. > Search highlighting might also be worth separating out so that we make sure that we focus on > getting searches done correctly, even if it turns out it is just a small enhancement on top. I assume > that this is referring to terms being highlighted when you click on a link result here so it is probably > out of scope of the Query result view section anyway. By "search highlighting" I meant highlighting of searching phrases in result set. Let's consider this as "low priority" feature. > I think that this could also be considered from the point of view of a set operation syntax which > could be interesting. Not sure if it is worth it of course. Anyway, in addition to logical operators, we > do need to be able to express a grouping syntax to build more advanced expressions from the > basics. What do you mean by grouping? More SQL like COUNT(...) GROUP BY or display results grouped by some fields? I'm thinking about creating separate sub-page for Resource Query requirements and syntax. Regards, Andrej On 22 November 2012 13:56, Gary Martin <[email protected]> wrote: > Next a few comments on the Query Result view and Resource Query sections: > > On 22/11/12 11:08, Andrej Golcov wrote: > >> Hi all, >> >> I've just added first draft of proposal for search improvements. So, let's >> discuss it :) >> >> I suggest that we agree on functional requirements and then pass to >> possible implementation. >> >> Regards, Andrej >> >> >> On 22 November 2012 11:32, Apache Bloodhound < >> bloodhound-dev@incubator.**apache.org<[email protected]>> >> wrote: >> >> Page "Proposals/BEP-0004" was added by andrej >>> Content: >>> -------8<------8<------8<-----**-8<------8<------8<------8<---** >>> ---8<-------- >>> >>> = BEP 4 : Improved search architecture #overview >>> >> [snip] > >> >>> === Query Result view >>> >>> Query Result view represents consistent view of query result for >>> different >>> resources. Result may be represented as >>> - All resources result tab - default, common for all resources columns >>> e.g. name and description >>> - Resource result tabs - resource specific fields are shown e.g. id, >>> status, summary for ticket. >>> - Query Result view can be instructed to limit result to specific >>> resource type e.g. show only tickets in result. In this case, resource >>> tabs >>> can be omitted. >>> >> > Presumably, this would be a part of the new query syntax so that it can be > relatively easy to filter before getting to this page. > >> User can refine search conditions either by editing query or by using >>> Query Builder. >>> >> > I would like to see others comment on the mockup for the query builder. > Consistency with other views suggest that there may be space on the right > hand side, replacing the activity area - I assume that we will not be > displying activity on any search/query screen. > > User can specify what fields should be selected and in what results order >>> should be applied. A new order type is introduced for free-text search: >>> score >>> >>> Query Result view should support facets ( >>> http://searchhub.org/2009/09/**02/faceted-search-with-solr/<http://searchhub.org/2009/09/02/faceted-search-with-solr/>) >>> for example: >>> - All resources result tab can show facets for resource type and >>> product >>> - Ticket result tab can show facets for products and ticket status >>> >> > Facets seem to me to be a very important enhancement. > >> >>> Other nice to have features in no particular order: >>> - Possibility to save a query for specific user and sharing of saved >>> queries >>> - Search highlighting >>> >> > Saved/stored queries have been discussed in the mailing list before a few > times so I think this is probably an expectation beyond the ability to put > a search macro on a wiki page. I think that this should probably be > considered separately of this solution but we should make sure that such > stored queries support any implementation that arises from this. > > Search highlighting might also be worth separating out so that we make > sure that we focus on getting searches done correctly, even if it turns out > it is just a small enhancement on top. I assume that this is referring to > terms being highlighted when you click on a link result here so it is > probably out of scope of the Query result view section anyway. > > === Resource Query >>> >>> New Resource Query should provide the following functionality: >>> - free-text search support >>> - facet support >>> - it is a superset of TracQuery functionality >>> >> So we can embed TracQuery syntax within the new queries? > >> - basic query expressions AND, OR, NOT, search by specific field, >>> search >>> [FROM TO] - TBD (can be similar to SQL or lucene/solr like) >>> >> > I think that this could also be considered from the point of view of a set > operation syntax which could be interesting. Not sure if it is worth it of > course. Anyway, in addition to logical operators, we do need to be able to > express a grouping syntax to build more advanced expressions from the > basics. > > It would also be nice if we were able to express these queries relatively > easily in a query string so that it is possible to just write your query > directly in a link and be understandable. > >> - search through different resources not only tickets: wiki, >>> milestones, >>> changesets and other pluggable resources >>> - search through all resource fields >>> - search through attachments, history and comments >>> - multi-product aware - apply security context etc >>> - order by free-text score. Score calculation can be configured, for >>> example if found in summary: id: score:100, score*10, in keywords: >>> score*5, >>> in components: score*3 … >>> >> > I would probably suggest that we keep configurability of scores in mind > but don't provide the interface to change it until a bit later. A bit of > clarification might be helpful here too. Presumably term found in summary > would be score*=100 rather than just assigned 100. In addition, we could > consider modifying the score based on the date. There is a further > possibility of including fairly simple "favour [something]" (e.g. "newer", > "older", etc) radio boxes to adjust the scoring dynamically as I am not > convinced that users should be expected to adjust these values for > themselves at the moment. > > Nice to have features >>> - Support search in attachments of specific types e.g word, exel etc. >>> >> I seem to remember that you get this in solr for free but I am not so > sure about the others. > > Cheers, > Gary >
