[
https://issues.apache.org/jira/browse/LUCENE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499700#comment-17499700
]
Andriy Redko commented on LUCENE-10432:
---------------------------------------
Thanks [~jpountz] , the examples you have provided are correct in illustrating
the limitation of the approach (without making changes in Apache Lucene
itself), the simple queries like
{noformat}
{
"query": {
"bool" : {
"_name": "my_query",
"should" : [
{ "term" : { "body" : "foo" } },
{ "term" : { "body" : "boo" } }
]
}
}
}
{
"query": {
{ "term" : { "body" : "foo", "_name": "my_query" } }
}
}{noformat}
could be covered, but the one you mentioned - indeed not
> Since explanations are used for debugging, it doesn't hurt to include
> information as part of the description compared to something more structured?
That's what we are trying to implement now (in most cases we are basically
constrained to either add `_name` to the end or at the start of the already
prepared description) , it does not hurt, but structured data is a bit easier
to interpret (and inject). I think we could close this issue, may not be worth
modifying if you don't see compelling use cases (besides this one), thank you.
> 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
