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=namne: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