[
https://issues.apache.org/jira/browse/LUCENE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499693#comment-17499693
]
Adrien Grand commented on LUCENE-10432:
---------------------------------------
I'd rather not touch explanation. Since queries don't have names, I don't
understand how a query could possibly do what you suggested in pseudo code
without adding dummy wrappers to queries whose purpose is only to set a name on
the explanation produced by the sub query. And these wrappers could make
queries run slower by preventing some rewrites, so this doesn't look like a
good trade-off to me.
The example use-case you provided suggested we could tag sub explanations
within the explanation tree with the name of the corresponding query, but
occasionally the query might no longer exist in that tree. For instance if you
consider this query (using Elasticsearch's query DSL):
{noformat}
{
"query": {
"bool" : {
"should" : [
{ "term" : { "body" : "foo" } },
{ "term" : { "body" : "foo", "_name": "my_query" } }
]
}
}
}
{noformat}
After rewriting this query would become a single query on {{body:foo^2}}. The
unboosted {{body:foo}} query that had {{my_query}} as a name no longer exists
and couldn't be tagged in the explanation tree.
I also prefer keeping the explanation API as simple as possible rather than
making it more structured. Since explanations are used for debugging, it
doesn't hurt to include information as part of the description compared to
something more structured?
> Add optional 'name' property to org.apache.lucene.search.Explanation
> ---------------------------------------------------------------------
>
> Key: LUCENE-10432
> URL: https://issues.apache.org/jira/browse/LUCENE-10432
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 9.0, 8.10.1
> Reporter: Andriy Redko
> Priority: Minor
>
> Right now, the `Explanation` class has the `description` property which is
> used pretty much as placeholder for free-style, human readable summary of
> what is happening. This is totally fine but it would be great to have a bit
> more formal way to link the explanation with corresponding function / query /
> filter if supported by the underlying engine.
> Example: Opensearch / Elasticseach has the concept of named queries / filters
> [1]. This is not supported by Apache Lucene at the moment but it would be
> helpful to propagate this information back as part of Explanation tree, for
> example by introducing optional 'name' property:
>
> {noformat}
> {
> "value": 0.0,
> "description": "script score function, computed with script: ...",
>
> "name": "script1",
> "details": [
> {
> "value": 1.0,
> "description": "_score: ",
> "details": [
> {
> "value": 1.0,
> "description": "*:*",
> "details": []
> }
> ]
> }
> ]
> }{noformat}
>
> From the other side, the `name` property may look like not belonging here,
> the alternative suggestion would be to add support of `properties` /
> `parameters` / `tags` key/value bag, for example:
>
> {noformat}
> {
> "value": 0.0,
> "description": "script score function, computed with script: ...",
>
> "tags": [
> { "name": "script1" }
> ],
> "details": [
> {
> "value": 1.0,
> "description": "_score: ",
> "details": [
> {
> "value": 1.0,
> "description": "*:*",
> "details": []
> }
> ]
> }
> ]
> }{noformat}
> The change should be non-breaking but quite useful for engines to enrich the
> `Explanation` with additional context.
> [1]
> https://www.elastic.co/guide/en/elasticsearch/reference/7.16/query-dsl-bool-query.html#named-queries
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
