org.apache.solr.response.transform

Class 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=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

    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 qubquery 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 differnet field values, in the subquery results.