[ 
https://issues.apache.org/jira/browse/LUCENE-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16221439#comment-16221439
 ] 

Robert Muir commented on LUCENE-8019:
-------------------------------------

By the way there exists a very simple example of such stuff in the unit tests: 
https://github.com/apache/lucene-solr/blob/master/lucene/core/src/test/org/apache/lucene/search/TestBooleanQueryVisitSubscorers.java#L262

I don't think we need to bring Collector into it as such a debug() would take 
docID and only work on one doc, so that would be overkill. but you can see 
traversal and the kind of assertions in unit tests such as:
{noformat}
assertEquals(
          "ConjunctionScorer\n" +
          "    MUST ConstantScoreScorer\n" +
          "    MUST MinShouldMatchSumScorer\n" +
          "            SHOULD TermScorer body:crawler\n" +
          "            SHOULD TermScorer body:web\n" +
          "            SHOULD TermScorer body:nutch",
              summary);
{noformat}

Output can use child.docID() == doc to determine if something matched or not, 
and maybe it can include stuff such as freq() and score() which may be enough 
to help debug issues as to why something matched or didnt match. You can always 
climb up Scorer -> Weight -> Query to get additional metadata/toString for 
improved output or to re-arrange things differently. I think it could be 
generally useful if we invested a little time.

Otherwise its frustrating that we bear the cost of maintaining a scorer tree 
api but don't use it for anything.

> Add a root failure cause to Explanation 
> ----------------------------------------
>
>                 Key: LUCENE-8019
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8019
>             Project: Lucene - Core
>          Issue Type: New Feature
>            Reporter: Mike Sokolov
>         Attachments: LUCENE_8019.patch
>
>
> If you need to analyze the root cause of a query's failure to match some 
> document, you can use the Weight.explain() API. If you want to do some gross 
> analysis of a whole batch of queries, say scraped from a log, that once 
> matched, but no longer do, perhaps after some refactoring or other 
> large-scale change, the Explanation isn't very good for that. You can try 
> parsing its textual output, which is pretty regular, but instead I found it 
> convenient to add some boolean structure to Explanation, and use that to find 
> failing leaves on the Explanation tree, and report only those.
> This patch adds a "condition" to each Explanation, which can be REQUIRED, 
> OPTIONAL, PROHIBITED, or NONE. The conditions correspond in obvious ways to 
> the Boolean Occur, except for NONE, which is used to indicate a node which 
> can't be further decomposed. It adds new Explanation construction methods for 
> creating Explanations with conditions (defaulting to NONE with the existing 
> methods).
> Finally Explanation.getFailureCauses() returns a list of Strings that are the 
> one-line explanations of the failing queries that, if some of them had 
> succeeded, would have made the original overall query match.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to