CODEWITHSUNDEEP
joinsolrsolrjsolrcloud
Shah Khalid
Shah Khalid

Reputation: 31

How to use join in solr in order to get result from both the cores?

I have two cores:

core 1: BookID, Venue, Title, Authors, PubDate

core 2: BookID, Text, Referenecs, Size, LastUpdated

http://localhost:8983/solr/core1/select?fl=Title,%20Venue,%20Authors,%20PubDate&q={!join%20from=PaperID%20to=fileName%20fromIndex=core2%20}size:15870

The above query returns zero results as:

<response>
   <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">0</int>
      <lst name="params">
         <str name="q">{!join from=PaperID to=fileName fromIndex=PapersIndex }size:15870</str>
         <str name="fl">Title, Venue</str>
      </lst>
   </lst>
   <result name="response" numFound="0" start="0" />
</response>

I don't know how the solr join works. Why does it give zero results?

Upvotes: 0

Views: 3252

Answers (2)

Shah Khalid
Shah Khalid

Reputation: 31

Solved out... pretty simple tried out the following query: 

http://localhost:8983/solr/core/select?q=*:*&%20fl=%20Title,Year&fq={!join%20from=BookID%20fromIndex=core2%20to=BookID}Year:2000

You can get fields from the first core as per some criteria based on second core.

Like I need field1, field2,..fieldn from core1 where core2.field="something"

Upvotes: 0

MatsLindh
MatsLindh

Reputation: 52792

Joins in Solr can't return results from both sides. Think of a join as "filtering the results by matching from a different core" (i.e. an INNER JOIN in regular SQL).

The reason why your example gives zero results is probably because you're joining the ID of one core against the SIZE in the other core. You want to join ID against ID (i.e. the common ID in both cores).

But you'll still only be able to return data from a single core / collection.

The solution to this is usually to index everything into the same core, although there's support for joins with data from both sides using streaming expressions (where each result is returned and then joined from both cursors), but I don't recommend basing your queries and index design on that from the scratch.

Upvotes: 6

Related Questions