The version it's working on is 8.5!
On Wed, 12 Aug 2020 at 17:16, Norbert Kutasi
wrote:
> I see what you mean, however the request results in cartesian products ,
> because of subordinate.q=*:* :
>
> http://localhost:8981/solr/Collection1/query?q=*&fl=*,subordinate:[subquery]&subordinate.q=*:*&
I see what you mean, however the request results in cartesian products ,
because of subordinate.q=*:* :
http://localhost:8981/solr/Collection1/query?q=*&fl=*,subordinate:[subquery]&subordinate.q=*:*&subordinate.fl=*&subordinate.collection=Collection2
{
"responseHeader":{
"zkConnected":true,
This works from a browser:
http://localhost:8981/solr/Collection1/query?q=*&fl=*,subordinate:[subquery]&subordinate.q=*:*&subordinate.fl=*&subordinate.collection=Collection2
One problem you’re having is that “fromIndex” is a _core_ not a collection. See:
https://lucene.apache.org/solr/guide/8_2/tr
Hi Dominique,
Sorry, I was in a hurry to create a simple enough yet similar case that we
face with internally.
reporting_to indeed is the right field , but the same error still persists,
something is seemingly wrong when invoking the *subquery *with *fromIndex*
{
params: {
q: "*",
fq:
Hi Norbert,
The field name in collection2 is "reporting_to" not "reporting".
Dominique
Le mer. 12 août 2020 à 11:59, Norbert Kutasi a
écrit :
> Hello,
>
> We have been using [subquery] to come up with arbitrary complex hierarchies
> in our document responses.
>
> It works well as long as th
