[
https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9448:
-----------------------------------
Summary: [subquery] calls another collection fails with (was: [subquery]
can't pull fields from SolrCloud collection if it has a differently named
uniqueKey)
> [subquery] calls another collection fails with
> -----------------------------------------------
>
> 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
>
>
> h2.UPD
> The sentences below seems not really actual. The more objective synopsis is
> described in the first comment. It seems like
> fl=foo:\[subquery]&collection=bar can be fixed just by declaring fields in
> schema.
> h3. Old description
> 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
