A Query Pipeline transforms a set of inputs into a Solr query request and it can execute requests and manipulate the Solr response as well, via a set of modularized operations called Query Stages. The objects sent from stage to stage are Request objects and Response objects.
Fusion stores pipeline names and definitions, allowing a pipeline to be reused across applications. Pipeline definitions can be modified, so that as an application evolves, the pipelines used by that application can evolve accordingly. During application development, the Fusion UI can be used to develop and debug a Query Pipeline.
The available stage types allow setting specific parameters for the query, such as the number of results to return or the query parser to use. You can also define facets and recommendations to be returned with the results. If Access Control Lists (ACLs) are in use, you can apply a security-trimming stage to apply user access restrictions to the results.
Default Query Pipelines
Fusion ships with one default query pipeline named 'default'.
This pipeline has the following pre-configured stages:
A Boost with Signals stage which boosts based on signals (if signals are collected and sent to the app).
A Query Fields stage which sets the default number of results returned to 10. The property "skip" is false and the property "condition" is empty, so that all queries are processed.
A Facets stage. No facet fields are specified. As configured, this stage has no effect on the pipeline.
A Solr Query stage which sends the full query request to Solr.
When a collection is created, a default query pipeline for the collection is created. The pipeline name is the collection name with '-default' appended. For example, collection foo will have default query pipeline foo-default. This pipeline has the same configuration as the pipeline named 'default'.