[jira] [Comment Edited] (SOLR-10059) In SolrCloud, every fq added via is computed twice.
[
https://issues.apache.org/jira/browse/SOLR-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213937#comment-17213937
]
Johannes Baiter edited comment on SOLR-10059 at 10/14/20, 2:01 PM:
---
I believe SOLR-14931 describes exactly the same issue in the above comment by
[~tboeghk], thank you [~cpoerschke]!
was (Author: jbaiter):
I believe SOLR-14931 describes exactly the issue [~tboeghk] described in the
above comment, thank you [~cpoerschke]!
> In SolrCloud, every fq added via is computed twice.
>
>
> Key: SOLR-10059
> URL: https://issues.apache.org/jira/browse/SOLR-10059
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.4
>Reporter: Marc Morissette
>Priority: Major
> Labels: performance
> Attachments: SOLR-10059_7x.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While researching another issue, I noticed that parameters appended to a
> query via SearchHandler's are added to the query twice
> in SolrCloud: once on the aggregator and again on the shard.
> The FacetComponent corrects this automatically by removing duplicates. Field
> queries added in this fashion are however computed twice and that hinders
> performance on filter queries that aren't simple bitsets such as those
> produced by the CollapsingQueryParser.
> To reproduce the issue, simply test this handler on a large enough
> collection, then replace "appends" with "defaults". You'll notice significant
> performance improvements.
> {code}
>
>
> {!collapse field=routingKey hint=top_fc}
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10059) In SolrCloud, every fq added via is computed twice.
[
https://issues.apache.org/jira/browse/SOLR-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213937#comment-17213937
]
Johannes Baiter commented on SOLR-10059:
I believe SOLR-14931 describes exactly the issue [~tboeghk] described in the
above comment, thank you [~cpoerschke]!
> In SolrCloud, every fq added via is computed twice.
>
>
> Key: SOLR-10059
> URL: https://issues.apache.org/jira/browse/SOLR-10059
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.4
>Reporter: Marc Morissette
>Priority: Major
> Labels: performance
> Attachments: SOLR-10059_7x.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While researching another issue, I noticed that parameters appended to a
> query via SearchHandler's are added to the query twice
> in SolrCloud: once on the aggregator and again on the shard.
> The FacetComponent corrects this automatically by removing duplicates. Field
> queries added in this fashion are however computed twice and that hinders
> performance on filter queries that aren't simple bitsets such as those
> produced by the CollapsingQueryParser.
> To reproduce the issue, simply test this handler on a large enough
> collection, then replace "appends" with "defaults". You'll notice significant
> performance improvements.
> {code}
>
>
> {!collapse field=routingKey hint=top_fc}
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14931) Macros in appends/invariants parameters not getting expanded in Solrcloud
Johannes Baiter created SOLR-14931:
--
Summary: Macros in appends/invariants parameters not getting
expanded in Solrcloud
Key: SOLR-14931
URL: https://issues.apache.org/jira/browse/SOLR-14931
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCloud
Affects Versions: 8.6.3, 7.6
Reporter: Johannes Baiter
Macros in a request handler's {{appends}} or {{invariants}} parameter sets are
not getting expanded when running in a SolrCloud setup.
In my case, I have a handler like the following:
{code:xml}
some_field:"$${my_term}"
term_defaults:'$${my_term},freq_defaults:docfreq(some_field,
'$${my_term}')
term_appends:'$${my_term}',freq_appends:docfreq(some_field,
'$${my_term}')
{code}
When querying the handler with `?my_term=foobar=all`, something like
this is the result:
{code:json}
{
"response": {
"docs": [
{
"term_defaults": "foobar",
"term_appends": "${my_term}",
"freq_appends": 0,
"freq_defaults": 1
}
],
"maxScore": 13.244947,
"numFound": 1,
"start": 0
},
"responseHeader": {
"QTime": 262091,
"params": {
"echoParams": "all",
"fl": [
"term_defaults:'foobar',freq_defaults:docfreq(some_field,
'foobar')",
"term_appends:'foobar',freq_appends:docfreq(some_field,
'foobar')"
],
"my_term": "foobar",
"q": "some_field:\"foobar\"",
"rows": "1"
},
"status": 0,
"zkConnected": true
}
}
{code}
As you can see, the macro in the {{appends}} {{fl}} parameter gets expanded in
the {{responseHeader.params.fl}} field, but not in the actual document.
I believe the reason for this is the following:
* Setting of defaults/invariants/appends happens once before the request gets
sent to the shards
* Here, macro expansion happens, i.e. the shards get the fully expanded
parameters
* On the shards, once again, defaults/invariants/appends are set
(https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java#L209)
* However, this time *macros are not expanded*
(https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/request/json/RequestUtil.java#L151-L161)
* For {{defaults}} parameters, this doesn't break anything, since the
(expanded) parameter from the request takes precedence over the server-supplied
value.
* However, for {{appends}}, both the expanded and the unexpanded version are
now set, while for {{invariants}} the expanded value is removed from the params
I think the easy/obvious fix for this would be not to set
{{defaults}}/{{invariants}}/{{appends}} parameters twice, i.e. disable it when
{{isShard=true}}, just like macro expansion, but I don't have the full picture
if that might not break something else.
Here's the Twitter thread where I rubber-ducked through this issue:
https://twitter.com/jbaiter_/status/1316023733576843272
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14913) Including non-existing field in edismax field alias breaks parsing of boolean query
[
https://issues.apache.org/jira/browse/SOLR-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14913:
---
Description:
When including a non-existing field in a {{f..qf}} field alias, boolean
queries are parsed incorrectly.
For non-boolean queries the invalid field is simply ignored, but in boolean
queries only the first search term is resolved to the fields from the alias,
while the second term is resolved to the {{_text_}} field.
This parse is identical to the parse obtained from the same query with
brackets removed, i.e. {{: ( )}} returns the exact same
parse as {{: }}.
I was able to reproduce this with the demo index in the latest Docker setup:
{{$ docker run --name solr_demo -d -p 8983:8983 solr:8 solr-demo}}
*Query:*
{code:bash}
$ curl "http://localhost:8983/solr/demo/select?\
debugQuery=on\
=edismax\
=name+manu+cat+features+idontexist\
=meta%3A%28samsung+noiseguard%29"
{code}
*Expected Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung)) (name:noiseguard | manu:noiseguard | features: noiseguard |
cat:noiseguard))" }
}
{code}
*Actual Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung) (_text_:noiseguard))" }
}
{code}
was:
When including a non-existing field in a {{f..qf}} field alias, boolean
queries are parsed incorrectly.
For non-boolean queries the invalid field is simply ignored, but in boolean
queries only the first search term is resolved to the fields from the alias,
while the second term is resolved to the {{_text_}} field.
This parse is identical to the parse obtained from the same query with
brackets removed, i.e. {{: ( ) }}returns the exact same
parse as{{ : }}.
I was able to reproduce this with the demo index in the latest Docker setup:
{{$ docker run --name solr_demo -d -p 8983:8983 solr:8 solr-demo}}
*Query:*
{code:bash}
$ curl "http://localhost:8983/solr/demo/select?\
debugQuery=on\
=edismax\
=name+manu+cat+features+idontexist\
=meta%3A%28samsung+noiseguard%29"
{code}
*Expected Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung)) (name:noiseguard | manu:noiseguard | features: noiseguard |
cat:noiseguard))" }
}
{code}
*Actual Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung) (_text_:noiseguard))" }
}
{code}
> Including non-existing field in edismax field alias breaks parsing of boolean
> query
> ---
>
> Key: SOLR-14913
> URL: https://issues.apache.org/jira/browse/SOLR-14913
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.6, 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
>
> When including a non-existing field in a {{f..qf}} field alias,
> boolean queries are parsed incorrectly.
> For non-boolean queries the invalid field is simply ignored, but in boolean
> queries only the first search term is resolved to the fields from the alias,
> while the second term is resolved to the {{_text_}} field.
> This parse is identical to the parse obtained from the same query with
> brackets removed, i.e. {{: ( )}} returns the exact same
> parse as {{: }}.
> I was able to reproduce this with the demo index in the latest Docker setup:
> {{$ docker run --name solr_demo -d -p 8983:8983 solr:8 solr-demo}}
> *Query:*
> {code:bash}
> $ curl "http://localhost:8983/solr/demo/select?\
> debugQuery=on\
> =edismax\
> =name+manu+cat+features+idontexist\
> =meta%3A%28samsung+noiseguard%29"
> {code}
> *Expected Parse:*
> {code:json}
> { "debug":
> { "parsedquery_toString": "+((name:samsung | manu:samsung |
> features:samsung | cat:samsung)) (name:noiseguard | manu:noiseguard |
> features: noiseguard | cat:noiseguard))" }
> }
> {code}
> *Actual Parse:*
> {code:json}
> { "debug":
> { "parsedquery_toString": "+((name:samsung | manu:samsung |
> features:samsung | cat:samsung) (_text_:noiseguard))" }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14913) Including non-existing field in edismax field alias breaks parsing of boolean query
[
https://issues.apache.org/jira/browse/SOLR-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14913:
---
Description:
When including a non-existing field in a {{f..qf}} field alias, boolean
queries are parsed incorrectly.
For non-boolean queries the invalid field is simply ignored, but in boolean
queries only the first search term is resolved to the fields from the alias,
while the second term is resolved to the {{_text_}} field.
This parse is identical to the parse obtained from the same query with
brackets removed, i.e. {{: ( ) }}returns the exact same
parse as{{ : }}.
I was able to reproduce this with the demo index in the latest Docker setup:
{{$ docker run --name solr_demo -d -p 8983:8983 solr:8 solr-demo}}
*Query:*
{code:bash}
$ curl "http://localhost:8983/solr/demo/select?\
debugQuery=on\
=edismax\
=name+manu+cat+features+idontexist\
=meta%3A%28samsung+noiseguard%29"
{code}
*Expected Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung)) (name:noiseguard | manu:noiseguard | features: noiseguard |
cat:noiseguard))" }
}
{code}
*Actual Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung) (_text_:noiseguard))" }
}
{code}
was:
When including a non-existing field in a {{f..qf}} field alias, boolean
queries are parsed incorrectly.
For non-boolean queries the invalid field is simply ignored, but in boolean
queries only the first search term is resolved to the fields from the alias,
while the second term is resolved to the {{_text_}} field.
This parse is identical to the parse obtained from the same query with
brackets removed, i.e. {{:( ) }}returns the exact same
parse as{{ : }}.
I was able to reproduce this with the demo index in the latest Docker setup:
{{$ docker run --name solr_demo -d -p 8983:8983 solr:8 solr-demo}}
*Query:*
{code:bash}
$ curl "http://localhost:8983/solr/demo/select?\
debugQuery=on\
=edismax\
=name+manu+cat+features+idontexist\
=meta%3A%28samsung+noiseguard%29"
{code}
*Expected Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung)) (name:noiseguard | manu:noiseguard | features: noiseguard |
cat:noiseguard))" }
}
{code}
*Actual Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung) (_text_:noiseguard))" }
}
{code}
> Including non-existing field in edismax field alias breaks parsing of boolean
> query
> ---
>
> Key: SOLR-14913
> URL: https://issues.apache.org/jira/browse/SOLR-14913
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.6, 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
>
> When including a non-existing field in a {{f..qf}} field alias,
> boolean queries are parsed incorrectly.
> For non-boolean queries the invalid field is simply ignored, but in boolean
> queries only the first search term is resolved to the fields from the alias,
> while the second term is resolved to the {{_text_}} field.
> This parse is identical to the parse obtained from the same query with
> brackets removed, i.e. {{: ( ) }}returns the exact same
> parse as{{ : }}.
> I was able to reproduce this with the demo index in the latest Docker setup:
> {{$ docker run --name solr_demo -d -p 8983:8983 solr:8 solr-demo}}
> *Query:*
> {code:bash}
> $ curl "http://localhost:8983/solr/demo/select?\
> debugQuery=on\
> =edismax\
> =name+manu+cat+features+idontexist\
> =meta%3A%28samsung+noiseguard%29"
> {code}
> *Expected Parse:*
> {code:json}
> { "debug":
> { "parsedquery_toString": "+((name:samsung | manu:samsung |
> features:samsung | cat:samsung)) (name:noiseguard | manu:noiseguard |
> features: noiseguard | cat:noiseguard))" }
> }
> {code}
> *Actual Parse:*
> {code:json}
> { "debug":
> { "parsedquery_toString": "+((name:samsung | manu:samsung |
> features:samsung | cat:samsung) (_text_:noiseguard))" }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14913) Including non-existing field in edismax field alias breaks parsing of boolean query
Johannes Baiter created SOLR-14913:
--
Summary: Including non-existing field in edismax field alias
breaks parsing of boolean query
Key: SOLR-14913
URL: https://issues.apache.org/jira/browse/SOLR-14913
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: query parsers
Affects Versions: 8.6.2, 7.6
Reporter: Johannes Baiter
When including a non-existing field in a {{f..qf}} field alias, boolean
queries are parsed incorrectly.
For non-boolean queries the invalid field is simply ignored, but in boolean
queries only the first search term is resolved to the fields from the alias,
while the second term is resolved to the {{_text_}} field.
This parse is identical to the parse obtained from the same query with
brackets removed, i.e. {{:( ) }}returns the exact same
parse as{{ : }}.
I was able to reproduce this with the demo index in the latest Docker setup:
{{$ docker run --name solr_demo -d -p 8983:8983 solr:8 solr-demo}}
*Query:*
{code:bash}
$ curl "http://localhost:8983/solr/demo/select?\
debugQuery=on\
=edismax\
=name+manu+cat+features+idontexist\
=meta%3A%28samsung+noiseguard%29"
{code}
*Expected Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung)) (name:noiseguard | manu:noiseguard | features: noiseguard |
cat:noiseguard))" }
}
{code}
*Actual Parse:*
{code:json}
{ "debug":
{ "parsedquery_toString": "+((name:samsung | manu:samsung | features:samsung
| cat:samsung) (_text_:noiseguard))" }
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191223#comment-17191223
]
Johannes Baiter edited comment on SOLR-14829 at 9/6/20, 7:38 AM:
-
{quote}Is it enough to merely define your search component with the name
"highlight" in solrconfig.xml, thus overriding the built-in one? Then you don't
even need to make any component changes to your handler definition.
{quote}
Unfortunately, no. The [custom
highlighter|https://dbmdz.github.io/solr-ocrhighlighting/] is supposed to run
alongside the regular highlighter, since it only takes care of highlighting a
specific subset of fields in the response, all other fields go through the
default highlighter.
But maybe it would be a good idea to add a warning to the section about
defining the {{components}} from scratch that this is a last resort (because of
mistakes like mine, and also for future-proofing in case other new default
components are added) and the other alternatives should be preferred?
was (Author: jbaiter):
{quote}
Is it enough to merely define your search component with the name "highlight"
in solrconfig.xml, thus overriding the built-in one? Then you don't even need
to make any component changes to your handler definition.
{quote}
Unfortunately, no. The [custom
highlighter|https://dbmdz.github.io/solr-ocrhighlighting/] is supposed to run
alongside the regular highlighter, since it only takes care of highlighting a
specific subset of fields in the response, all other fields go through the
default highlighter.
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191223#comment-17191223
]
Johannes Baiter edited comment on SOLR-14829 at 9/6/20, 7:38 AM:
-
{quote}Is it enough to merely define your search component with the name
"highlight" in solrconfig.xml, thus overriding the built-in one? Then you don't
even need to make any component changes to your handler definition.
{quote}
Unfortunately, no. The [custom
highlighter|https://dbmdz.github.io/solr-ocrhighlighting/] is supposed to run
alongside the regular highlighter, since it only takes care of highlighting a
specific subset of fields in the response, all other fields go through the
default highlighter.
Maybe it would be a good idea to add a warning to the section about defining
the {{components}} from scratch that this is a last resort (because of mistakes
like mine, and also for future-proofing in case other new default components
are added) and the other alternatives should be preferred?
was (Author: jbaiter):
{quote}Is it enough to merely define your search component with the name
"highlight" in solrconfig.xml, thus overriding the built-in one? Then you don't
even need to make any component changes to your handler definition.
{quote}
Unfortunately, no. The [custom
highlighter|https://dbmdz.github.io/solr-ocrhighlighting/] is supposed to run
alongside the regular highlighter, since it only takes care of highlighting a
specific subset of fields in the response, all other fields go through the
default highlighter.
But maybe it would be a good idea to add a warning to the section about
defining the {{components}} from scratch that this is a last resort (because of
mistakes like mine, and also for future-proofing in case other new default
components are added) and the other alternatives should be preferred?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191223#comment-17191223
]
Johannes Baiter commented on SOLR-14829:
{quote}
Is it enough to merely define your search component with the name "highlight"
in solrconfig.xml, thus overriding the built-in one? Then you don't even need
to make any component changes to your handler definition.
{quote}
Unfortunately, no. The [custom
highlighter|https://dbmdz.github.io/solr-ocrhighlighting/] is supposed to run
alongside the regular highlighter, since it only takes care of highlighting a
specific subset of fields in the response, all other fields go through the
default highlighter.
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191009#comment-17191009
]
Johannes Baiter commented on SOLR-14829:
{quote}Would you like to open a new JIRA issue on those concerns so that I can
invite a wider discussion around it from some of the committers who are in the
best position to resolve this
{quote}
Sure, I'll try to get a better picture of the code/architecture first, though,
so I have a better picture of it and am not just ranting based on some
superficial observations :-)
{quote}In your own/custom definition of your request handler, do you need to
actually list these components at all, vs just rely on the default list? I
think most people by far let the defaults happen.
{quote}
Yeah, in my case I have a custom highlight component that I want to have on my
handler. Sure, there's {{first-components}} and {{last-components}}, which
would probably better for this case.
But I think we can agree that if there's an option to define your own
{{components}}, the documentation on the defaults for this option should be
correct so that users can operate under the right assumptions? Especially since
the documentation treats {{first-components}}, {{last-components}} and
{{components}} as equals, i.e. there's no comment indicating that the former
two might be preferable because they're "safer"?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Description:
In the reference guide, the list of search components that are enabled by
default is missing the {{facet_module}} and {{terms}} components. The terms
component is instead listed under "other useful components", while the
{{FacetModule}} is never listed anywhere in the documentation, despite it being
neccessary for the JSON Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component}} package?
was:
In the reference guide, the list of search components that are enabled by
default is missing the {{facet_module}} and {{terms}} components. The terms
component is instead listed under "other useful components", while the
{{FacetModule}} is never listed anywhere in the documentation, despite it being
neccessary for the JSON Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Priority: Minor (was: Major)
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Description:
In the reference guide, the list of search components that are enabled by
default is missing the {{facet_module}} and {{terms}} components. The terms
component is instead listed under "other useful components", while the
{{FacetModule}} is never listed anywhere in the documentation, despite it being
neccessary for the JSON Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
was:
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms}} components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Description:
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms}} components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
was:
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms }}components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
> Attachments: SOLR-14829.patch
>
>
> The list of search components that are enabled by default is missing the
> {{facet_module}} and {{terms}} components. The terms component is instead
> listed under "other useful components", while the {{FacetModule}} is never
> listed anywhere in the documentation, despite it being neccessary for the
> JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail:
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Attachment: SOLR-14829.patch
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
> Attachments: SOLR-14829.patch
>
>
> The list of search components that are enabled by default is missing the
> {{facet_module}} and {{terms }}components. The terms component is instead
> listed under "other useful components", while the {{FacetModule}} is never
> listed anywhere in the documentation, despite it being neccessary for the
> JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14829) Default components are missing facet_module and terms in documentation
Johannes Baiter created SOLR-14829:
--
Summary: Default components are missing facet_module and terms in
documentation
Key: SOLR-14829
URL: https://issues.apache.org/jira/browse/SOLR-14829
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: documentation
Affects Versions: 8.6.2
Reporter: Johannes Baiter
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms }}components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
