[
https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9448:
-----------------------------------
Attachment: SOLR-9448.patch
ok. reproduced it with attached test case. The synopsis is:
if we request one collection from another
{{/people/select?q=department_text:foo&collection=departments}} the query is
unnecessary parsed in {{people}} collection where it can hit a wall if schemas
are different.
{code}
@Test
public void testJustCrossCollectionRequest() throws SolrServerException,
IOException {
cluster.getSolrClient().request(new QueryRequest(
params( "q","departments_text:foo",
"collection","departments")
), "people");
}
{code}
{quote}
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:52548/solr/people_shard1_replica1: undefined
field departments_text
at
__randomizedtesting.SeedInfo.seed([1E3C35306C9B6800:E9590C1B5403419]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:608)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:415)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:367)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1280)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.testJustCrossCollectionRequest(TestSubQueryTransformerDistrib.java:200)
{quote}
So, suggested workaround is just to declare fields from the secondary
collection or wildcard just to pass unnecessary query parsing.
h3. Question to developers
Don't we need to bypass query parsing in QueryComponent.prepare() when it's
followed by distributed processing? If we do, I can come up with the patch.
> [subquery] can't pull fields from SolrCloud collection if it has a
> differently named uniqueKey
> ----------------------------------------------------------------------------------------------
>
> Key: SOLR-9448
> URL: https://issues.apache.org/jira/browse/SOLR-9448
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: 6.1, 6.2
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Attachments: SOLR-9448.patch
>
>
> straightforward \[subquery] implementation executes requests on a caller
> collection, but just hitting another one with
> {{caller/select?q=..&collection=callee}}. The problem is that for
> {{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one.
> Another observation, at that case both single sharded collections are
> collocated at the same instance. Then, subquery can't be parsed if it queries
> a field which are absent in caller schema. All of this seems pretty strange
> like hitting an edge case.
> h2. workaround
> Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
> Or you can name uniqKey the same, keeping the different app semantic.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
