[jira] [Created] (LUCENE-10442) When indexQuery or/and dvQuery be a MatchAllDocsQuery then IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery
Lu Xugang created LUCENE-10442: -- Summary: When indexQuery or/and dvQuery be a MatchAllDocsQuery then IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery Key: LUCENE-10442 URL: https://issues.apache.org/jira/browse/LUCENE-10442 Project: Lucene - Core Issue Type: Improvement Reporter: Lu Xugang IndexOrDocValuesQuery is typically useful for range queries, When indexQuery was rewrite to MatchAllDocsQuery and IndexOrDocValuesQuery will not be as a lead iterator , it most likely that dvQuery will supply the Scorer. -- 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
[GitHub] [lucene] iverase commented on pull request #709: LUCENE-10311: remove complex cost estimation and abstraction leakage around it
iverase commented on pull request #709: URL: https://github.com/apache/lucene/pull/709#issuecomment-1050646004 I remove the parameter `grown` from `addAll` in [4c6b436](https://github.com/apache/lucene/pull/709/commits/4c6b436c7059742c80a7975a39b72494082c543c) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10442) When indexQuery or/and dvQuery be a MatchAllDocsQuery then IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery
[ https://issues.apache.org/jira/browse/LUCENE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lu Xugang updated LUCENE-10442: --- Fix Version/s: 9.1 > When indexQuery or/and dvQuery be a MatchAllDocsQuery then > IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery > - > > Key: LUCENE-10442 > URL: https://issues.apache.org/jira/browse/LUCENE-10442 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Lu Xugang >Priority: Trivial > Fix For: 9.1 > > > IndexOrDocValuesQuery is typically useful for range queries, When indexQuery > was rewrite to MatchAllDocsQuery and IndexOrDocValuesQuery will not be as a > lead iterator , it most likely that dvQuery will supply the Scorer. > > -- 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
[jira] [Updated] (LUCENE-10442) When indexQuery or/and dvQuery be a MatchAllDocsQuery then IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery
[ https://issues.apache.org/jira/browse/LUCENE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lu Xugang updated LUCENE-10442: --- Description: IndexOrDocValuesQuery is typically useful for range queries, When indexQuery was rewrite to MatchAllDocsQuery and IndexOrDocValuesQuery not be as a lead iterator , it most likely that dvQuery will supply the Scorer. was: IndexOrDocValuesQuery is typically useful for range queries, When indexQuery was rewrite to MatchAllDocsQuery and IndexOrDocValuesQuery will not be as a lead iterator , it most likely that dvQuery will supply the Scorer. > When indexQuery or/and dvQuery be a MatchAllDocsQuery then > IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery > - > > Key: LUCENE-10442 > URL: https://issues.apache.org/jira/browse/LUCENE-10442 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Lu Xugang >Priority: Trivial > Fix For: 9.1 > > > IndexOrDocValuesQuery is typically useful for range queries, When indexQuery > was rewrite to MatchAllDocsQuery and IndexOrDocValuesQuery not be as a lead > iterator , it most likely that dvQuery will supply the Scorer. > > -- 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
[GitHub] [lucene] LuXugang opened a new pull request #715: LUCENE-10442: When indexQuery or/and dvQuery be a MatchAllDocsQuery then IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery
LuXugang opened a new pull request #715: URL: https://github.com/apache/lucene/pull/715 IndexOrDocValuesQuery is typically useful for range queries, When indexQuery was rewrite to MatchAllDocsQuery and IndexOrDocValuesQuery not be as a lead iterator , it most likely that dvQuery will supply the Scorer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] iverase commented on pull request #709: LUCENE-10311: remove complex cost estimation and abstraction leakage around it
iverase commented on pull request #709: URL: https://github.com/apache/lucene/pull/709#issuecomment-1050699040 Oh, but that might still be not correct. The buffers implementation does not grow with unique documents but with every call of BulkAdder#add because it does not discard duplicates. What I did only works if I assume that providing Integer.MAX_VALUE, the builder can add any number of calls to BulkAdder#add. Something is not totally right here as Buffers requires to know how many calls you are gonna be doing to BulkAdder#add and not the number of unique documents you are adding. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10442) When indexQuery or/and dvQuery be a MatchAllDocsQuery then IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery
[ https://issues.apache.org/jira/browse/LUCENE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lu Xugang updated LUCENE-10442: --- Description: IndexOrDocValuesQuery is typically useful for range queries, When indexQuery was rewrite to MatchAllDocsQuery and if IndexOrDocValuesQuery not be a lead iterator , it most likely that dvQuery will supply the Scorer not indexQuery. was: IndexOrDocValuesQuery is typically useful for range queries, When indexQuery was rewrite to MatchAllDocsQuery and IndexOrDocValuesQuery not be as a lead iterator , it most likely that dvQuery will supply the Scorer. > When indexQuery or/and dvQuery be a MatchAllDocsQuery then > IndexOrDocValuesQuery should be rewrite to MatchAllDocsQuery > - > > Key: LUCENE-10442 > URL: https://issues.apache.org/jira/browse/LUCENE-10442 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Lu Xugang >Priority: Trivial > Fix For: 9.1 > > Time Spent: 10m > Remaining Estimate: 0h > > IndexOrDocValuesQuery is typically useful for range queries, When indexQuery > was rewrite to MatchAllDocsQuery and if IndexOrDocValuesQuery not be a lead > iterator , it most likely that dvQuery will supply the Scorer not indexQuery. -- 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
[GitHub] [lucene] rmuir commented on pull request #709: LUCENE-10311: remove complex cost estimation and abstraction leakage around it
rmuir commented on pull request #709: URL: https://github.com/apache/lucene/pull/709#issuecomment-1050869655 There's no way we're allowing more than `Integer.MAX_VALUE` calls going to this buffers thing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10443) Remove one of SparseFixedBitSet/DocIdSetBuilder.Buffer
Robert Muir created LUCENE-10443: Summary: Remove one of SparseFixedBitSet/DocIdSetBuilder.Buffer Key: LUCENE-10443 URL: https://issues.apache.org/jira/browse/LUCENE-10443 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir SparseFixedBItSet is no longer used by DocIdSetBuilder, but the class didn't get cleaned up and removed. We only need one sparse representation and don't need to just litter up the codebase with unnecessary classes. -- 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
[GitHub] [lucene] rmuir commented on pull request #709: LUCENE-10311: remove complex cost estimation and abstraction leakage around it
rmuir commented on pull request #709: URL: https://github.com/apache/lucene/pull/709#issuecomment-1050876486 seriously, look at `threshold`. its `maxDoc >>> 7`. `maxDoc` is an int. when you call `grow(anywhere close to Integer.MAX_VALUE)` then buffers exits the stage permanently. 64 bits are not needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] iverase commented on pull request #709: LUCENE-10311: remove complex cost estimation and abstraction leakage around it
iverase commented on pull request #709: URL: https://github.com/apache/lucene/pull/709#issuecomment-1050884300 What I want to make sure is this is covered in the javadocs and we are not relying on an implementation detail. #grow needs to be called with the number of times you are going to be calling BulkAdder#addDoc in order to make sure you don't overflow the sparse data structure. That should be added to the javadocs and maybe avoid the word documents that is causing all the confusion here. We can add that if grow is called with Integer.MAX_VALUE, there are not limit to the calls or something along those lines. wdyt? Finally, we might need to modify the `AssertingLeafReader` as it asserts that you call #grow with the number of points you are going to visit, which in this case is not true all the time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10444) Support alternate aggregation functions in association facets
Greg Miller created LUCENE-10444:
Summary: Support alternate aggregation functions in association
facets
Key: LUCENE-10444
URL: https://issues.apache.org/jira/browse/LUCENE-10444
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Greg Miller
We currently only support {{sum}} aggregations in the various association facet
implementations. I'd be really interested in extending the association facet
implementations to support other aggregations, starting with {{max}} and
{{min}} (in addition to {{{}sum{}}}).
I've been sketching up a prototype of this and I think I have a reasonable way
to introduce this idea. Will get a PR out for feedback soon.
--
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
[jira] [Assigned] (LUCENE-10444) Support alternate aggregation functions in association facets
[
https://issues.apache.org/jira/browse/LUCENE-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Miller reassigned LUCENE-10444:
Assignee: Greg Miller
> Support alternate aggregation functions in association facets
> -
>
> Key: LUCENE-10444
> URL: https://issues.apache.org/jira/browse/LUCENE-10444
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
>Reporter: Greg Miller
>Assignee: Greg Miller
>Priority: Minor
>
> We currently only support {{sum}} aggregations in the various association
> facet implementations. I'd be really interested in extending the association
> facet implementations to support other aggregations, starting with {{max}}
> and {{min}} (in addition to {{{}sum{}}}).
> I've been sketching up a prototype of this and I think I have a reasonable
> way to introduce this idea. Will get a PR out for feedback soon.
--
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
[GitHub] [lucene] iverase edited a comment on pull request #709: LUCENE-10311: remove complex cost estimation and abstraction leakage around it
iverase edited a comment on pull request #709: URL: https://github.com/apache/lucene/pull/709#issuecomment-1050884300 What I want to make sure is this is covered in the javadocs and we are not relying on an implementation detail. #grow needs to be called with the number of times you are going to be calling BulkAdder#addDoc in order to make sure you don't overflow the sparse data structure. That should be added to the javadocs and maybe avoid the word documents that is causing all the confusion here. We can add that if grow is called with Integer.MAX_VALUE, there is not limit to the calls to BulkAdder#addDoc or something along those lines. wdyt? Finally, we might need to modify the `AssertingLeafReader` as it asserts that you call #grow with the number of points you are going to visit, which in this case is not true all the time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] andywebb1975 commented on pull request #2643: SOLR-9359 Make Config API work for warming queries
andywebb1975 commented on pull request #2643:
URL: https://github.com/apache/lucene-solr/pull/2643#issuecomment-1051012958
Thanks Eric! Yes, I'll do some refactoring and try making a test. I don't
think we get much control of the shape of the object - I'd like to be able to
drop the nested array and use a nice clean list like the below, but for some
reason only the first entry makes it into the output of `.get("queries")` :-(
```
{
"update-listener": {
"name": "warming-queries",
"event": "newSearcher",
"class": "solr.QuerySenderListener",
"queries": [
{
"q": "foo"
},
{
"q": "bar"
}
]
}
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10432) Add optional 'name' property to org.apache.lucene.search.Explanation
[
https://issues.apache.org/jira/browse/LUCENE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17498238#comment-17498238
]
Andriy Redko commented on LUCENE-10432:
---
[~jpountz] as progressed along the use cases, I have exact answer to your
question / concern: {{Weight#explain }}does not need to be changed, not the
Query, the Explanation could be copied & enriched in place, if need, an
example in pseudo code is below:
{noformat}
Explanation expl = subQueryWeight.explain(context, doc)
return // copy of expl with (description += query name); {noformat}
PS: I am using the `description` here as of today, but imagine the following
alternatives:
{noformat}
return expl.copyWithName(query name); {noformat}
{noformat}
return expl.copyWithTags("name", "query name"); {noformat}
WDYT?
> 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
[jira] [Comment Edited] (LUCENE-10432) Add optional 'name' property to org.apache.lucene.search.Explanation
[
https://issues.apache.org/jira/browse/LUCENE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17498238#comment-17498238
]
Andriy Redko edited comment on LUCENE-10432 at 2/25/22, 7:59 PM:
-
[~jpountz] as progressed along the use cases, I have exact answer to your
question / concern: \{{Weight#explain }}does not need to be changed, northe
Query, the Explanation could be copied & enriched in place, if needed, an
example in pseudo code is below:
{noformat}
Explanation expl = subQueryWeight.explain(context, doc)
return // copy of expl with (description += query name); {noformat}
PS: I am using the `description` here as of today, but imagine the following
alternatives:
{noformat}
return expl.copyWithName(query name); {noformat}
{noformat}
return expl.copyWithTags("name", "query name"); {noformat}
WDYT?
was (Author: reta):
[~jpountz] as progressed along the use cases, I have exact answer to your
question / concern: {{Weight#explain }}does not need to be changed, not the
Query, the Explanation could be copied & enriched in place, if need, an
example in pseudo code is below:
{noformat}
Explanation expl = subQueryWeight.explain(context, doc)
return // copy of expl with (description += query name); {noformat}
PS: I am using the `description` here as of today, but imagine the following
alternatives:
{noformat}
return expl.copyWithName(query name); {noformat}
{noformat}
return expl.copyWithTags("name", "query name"); {noformat}
WDYT?
> 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
[GitHub] [lucene] javanna opened a new pull request #716: LUCENE-10002: Replace test usages of TopScoreDocCollector with a corresponding collector manager
javanna opened a new pull request #716: URL: https://github.com/apache/lucene/pull/716 This is another one of many steps towards resolution of LUCENE-10002. In the effort or replacing usages of IndexSearcher#search(Query, Collector) with IndexSearcher#search(Query, CollectorManager), this commit replaces many test usages of TopScoreDocCollector with its corresponding CollectorManager created by calling TopScoreDocCollector#createSharedManager. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-10432) Add optional 'name' property to org.apache.lucene.search.Explanation
[
https://issues.apache.org/jira/browse/LUCENE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17498238#comment-17498238
]
Andriy Redko edited comment on LUCENE-10432 at 2/25/22, 9:25 PM:
-
[~jpountz] as progressed along the use cases, I have exact answer to your
question / concern: \{{Weight#explain }} does not need to be changed, nor the
Query, the Explanation could be copied & enriched in place, if needed, an
example in pseudo code is below:
{noformat}
Explanation expl = subQueryWeight.explain(context, doc)
return // copy of expl with (description += query name); {noformat}
PS: I am using the `description` here as of today, but imagine the following
alternatives:
{noformat}
return expl.copyWithName(query name); {noformat}
{noformat}
return expl.copyWithTags("name", "query name"); {noformat}
But surely, not bullet proof option (fe BooleanWeight#explain) but at least
having the way to propagate such context is already helpful.
WDYT?
was (Author: reta):
[~jpountz] as progressed along the use cases, I have exact answer to your
question / concern: \{{Weight#explain }}does not need to be changed, northe
Query, the Explanation could be copied & enriched in place, if needed, an
example in pseudo code is below:
{noformat}
Explanation expl = subQueryWeight.explain(context, doc)
return // copy of expl with (description += query name); {noformat}
PS: I am using the `description` here as of today, but imagine the following
alternatives:
{noformat}
return expl.copyWithName(query name); {noformat}
{noformat}
return expl.copyWithTags("name", "query name"); {noformat}
WDYT?
> 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
