lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Khludnev (JIRA)" <>
Subject [jira] [Updated] (SOLR-9448) [subquery] calls another collection fails with "undefined field" or NPE from mergeIds
Date Fri, 23 Dec 2016 20:40:58 GMT


Mikhail Khludnev updated SOLR-9448:
    Attachment:     (was: SOLR-9448.patch)

> [subquery] calls another collection fails with "undefined field" or NPE from mergeIds
> -------------------------------------------------------------------------------------
>                 Key: SOLR-9448
>                 URL:
>             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, SOLR-9448.patch, 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message