[
https://issues.apache.org/jira/browse/LUCENE-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227274#comment-16227274
]
Robert Muir commented on LUCENE-8019:
-------------------------------------
Yes, maybe post the code: i don't think we should give up on doing the right
thing just because of the impl of ReqExclScorer, these things could be changed.
I don't think we need to cast Weights to anything, it is probably enough to
just organize scorers with the Query that generated them (just use .toString
and .equals for de-duping and output, no casts needed).
It doesn't make sense to me to complicate Explanation with matching stuff, and
definitely not to do that and at the same time keep Scorer.getChildren api
(which is intended to do this kind of stuff). I'd rather fix the latter api
> 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]
