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 <
[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/) 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
