Package org.apache.solr.response.transform

Class SubQueryAugmenterFactory

java.lang.Object
org.apache.solr.response.transform.TransformerFactory
org.apache.solr.response.transform.SubQueryAugmenterFactory
All Implemented Interfaces:
NamedListInitializedPlugin
public class SubQueryAugmenterFactory extends TransformerFactory
This transformer executes subquery per every result document. It must be given an unique name. There might be a few of them, eg fl=*,foo:[subquery],bar:[subquery]. Every [subquery] occurrence adds a field into a result document with the given name, the value of this field is a document list, which is a result of executing subquery using document fields as an input.

Subquery Parameters Shift

if subquery is declared as fl=*,foo:[subquery], subquery parameters are prefixed with the given name and period. eg
q=*:*&fl=*,foo:[subquery]&foo.q=to be continued&foo.rows=10&foo.sort=id desc

Document Field As An Input For Subquery Parameters

It's necessary to pass some document field value as a parameter for subquery. It's supported via implicit row.fieldname parameters, and can be (but might not only) referred via Local Parameters syntax.
q=name:john&fl=name,id,depts:[subquery]&depts.q={!terms f=id v=$row.dept_id}&depts.rows=10 Here departments are retrieved per every employee in search result. We can say that it's like SQL join ON emp.dept_id=dept.id
Note, when document field has multiple values they are concatenated with comma by default, it can be changed by foo:[subquery separator=' '] local parameter, this mimics TermsQParserPlugin to work smoothly with.

Cores And Collections In SolrCloud

use foo:[subquery fromIndex=departments] invoke subquery on another core on the same node, it's like JoinQParserPlugin for non SolrCloud mode. But for SolrCloud just (and only) explicitly specify its' native parameters like collection, shards for subquery, eg
q=*:*&fl=*,foo:[subquery]&foo.q=cloud&foo.collection=departments

When used in Real Time Get

When used in the context of a Real Time Get, the values from each document that are used in the subquery are the "real time" values (possibly from the transaction log), but the query itself is still executed against the currently open searcher. Note that this means if a document is updated but not yet committed, an RTG request for that document that uses [subquery] could include the older (committed) version of that document, with different field values, in the subquery results.