[
https://issues.apache.org/jira/browse/SOLR-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-9377:
---------------------------
Attachment: SOLR-9377.patch
I was working on some javadoc and test fixes to treat it as expected that
{{\[subquery\]}} uses the regular searcher for the sub-request, when I
uncovered a slightly broader bug that isn't constrained to uncommited RTG docs
-- it can also bite you if you don't have a documentCache and don't
enableLazyFieldLoading in your configs (the realtime searcher that RTG can use
in some cases doesn't use any caching, and the existing solrconfig-tlog.xml
used by the RTG tests doesn't enableLazyFieldLoading)
Here's an example of what this failure looks like...
{noformat}
# start example
$ bin/solr -e techproducts
...
# disable autocommit & lazy field loading
$ curl --data-binary
'{"set-property":{"updateHandler.autoSoftCommit.maxTime":"-1"},"set-property":{"query.enableLazyFieldLoading":false}}'
-H 'Content-Type: application/json'
'http://localhost:8983/solr/techproducts/config'
...
# re-index w/o doing a commit
$ bin/post -commit no -c techproducts example/exampledocs/*.xml
...
# do an RTG that involves:
# - a function in the fl (so RTG uses a realtime searcher)
# - a subquery in the fl that refers to field not otherwise included in the fl
-- ie: price
#
# ...this will fail because the qubquery execution can't find a value for
"$row.price" so
# the sub-request query parsing fails
#
$ curl
'http://localhost:8983/solr/techproducts/get?indent=true&id=SOLR1000&fl=id,product(popularity,3)&fl=xxx:%5Bsubquery%5D&xxx.q=%7B!field+f=price+v=$row.price%7D'
{
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException"],
"msg":"while invoking xxx:[subquery] on
doc=SolrDocument{id=stored,indexed,tokenized,omitNorms,indexOptions=DOCS<id:SOLR1000>,
_version_=1542133",
"code":400}}
{noformat}
here's the same problem demonstrated with a regular search...
{noformat}
# hack to force documentCache to not init properly (no straight forward way to
disable via API)
# NOTE: expected to cause errors in log
$ curl --data-binary
'{"set-property":{"query.documentCache.initialSize":"-1"}}' -H 'Content-Type:
application/json' 'http://localhost:8983/solr/techproducts/config'
# do a simple query that involves:
# - a subquery in the fl that refers to field not otherwise included in the fl
(price)
#
# ...this will fail because the qubquery execution can't find a value for
"$row.price" so
# the sub-request query parsing fails
$ curl
'http://localhost:8983/solr/techproducts/select?indent=true&q=id:SOLR1000&fl=id&fl=xxx:%5Bsubquery%5D&xxx.q=%7B!field+f=price+v=$row.price%7D'
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="error">
<lst name="metadata">
<str name="error-class">org.apache.solr.common.SolrException</str>
<str name="root-error-class">org.apache.solr.common.SolrException</str>
</lst>
<str name="msg">while invoking xxx:[subquery] on
doc=SolrDocument{id=stored,indexed,tokenized,omitNorms,indexOptions=DOCS<id:SOLR1000>}</str>
<int name="code">400</int>
</lst>
</response>
{noformat}
----
The "right" way to fix this is to have
{{SubQueryAugmenter.getExtraRequestFields()}} return the list of field names it
expects to find in the docs being transformed, but unfortunately I can't think
of any way to identify the list of all {{$row.\*}} params used in the subquery.
So for now, this patch works around this bug (which i'll file in a new jira
soon) by only refering to fields in {{$row.\*}} parms that it knows for
certainly are included in the "fl" (ie: "id")
> [subquery] augmenter doesn't work with RTG on uncommited docs
> -------------------------------------------------------------
>
> Key: SOLR-9377
> URL: https://issues.apache.org/jira/browse/SOLR-9377
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Attachments: SOLR-9377.patch
>
>
> Spinning off from SOLR-9314...
> The {{[subquery]}} DocTransformer can give unexpected results when used with
> RTG on uncommitted docs.
> Test code demonstrating the problem is being added to TestRandomFlRTGCloud as
> part of SOLR-9314, but it's being disabled for now due to this current bug.
> As noted in that jira...
> {quote}
> The subquery validation tries to search for all docs with teh same field
> value as the current doc, asserting that there is always at least 1 match –
> but this assertion currently fails ... by the looks of it this is (obviously)
> because it doesn't know to to use the realtime seracher re-opened by the RTG
> ... but based on how the SubQueryAugmenter is implemented, i'm not even
> certain how to go about it.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
