Edgewall Software

Changes between Version 1 and Version 2 of SearchRefactoring


Ignore:
Timestamp:
May 30, 2007, 6:20:05 PM (17 years ago)
Author:
Christian Boos
Comment:

Added some notes about the current status of the branch

Legend:

Unmodified
Added
Removed
Modified
  • SearchRefactoring

    v1 v2  
    2626
    2727== Proposed Solutions ==
    28 ''(to be completed...)''
     28=== Ranking ===
     29
     30While trying different ranking ideas, I found that the major problem was managing to rank the results coming from different sources together in a fair way. For that, a "neutral" measure was needed. Such a measure can be the "number of hits" for the search terms within the matched resource. The basic idea is that each time the sequence of search terms appear "somewhere" in the text associated to a resource, this counts for one hit. This means that if there's a hit in a multi-line text field (like a wiki page content, or a ticket description or comment), we can search for multiple occurrences of the match and therefore add more "hits". Also, a source can decide that some hits are weighing more than others, like a hit in a "keywords" field.
     31
     32The search page now presents the results entries ordered by relevance, the highest ranking entries first.
     33
     34Nevertheless, it's still possible to look at the results in chronological order. This can be achieved by following the "Results by date" page navigation link, which leads to a ''Timeline'' style page showing the results ordered by date, most recent entries first.
     35
     36=== Reuse of results ===
     37
     38Implemented the proposal made in trac-dev:335 to "send" the list of matched tickets to the Ticket Query view, for further refinement of the search.
     39
     40This is done by adding an 'alternate' format link named ''Ticket Query''.
     41
     42Likewise, it would be possible to send the changeset found to a log listing, which also now supports a list of individual changesets.
     43
     44=== Direct access to resources by their numbers ===
     45
     46The initial solution for #1268 suffers from some drawbacks, most notably that it doesn't match the exact number but a substring of it: this generates many false positives. We should not only match the exact id, but also present it as an "outstanding result", like TracLinks matches, presented in a special way.
     47This can now be achieved at the level of the search provider, as it can return a result with a "special" weight.
     48
     49''#1268 is still opened at this point, as well as #4398''
     50
     51-----
    2952
    3053Implemented so far:
    3154 - log:sandbox/search-api-tmp
    32 
    3355
    3456Other minor glitches: