You can think of it like faceted search, except instead of just getting a count, you get the top documents for that constraint or category. There are tons of potential use cases:

• For web search, only show 1 or 2 results for a given website by collapsing on a site field.
• For email search, only show 1 or 2 results for a given email thread
• For e-commerce, show the top 3 products for each store category (i.e. “electronics”, “housewares”)
• Hiding duplicate documents at query time.

In addition to being able to group by the values of a field, you can also group by the values of a function query. Given that geo search works as a function query, this also opens up possibilities for showing top query matches within 1 mile, between 1 and 2 miles, etc.

Just like faceting, we’ll be adding new functionality and making continual improvements.
Result Grouping is documented on the Solr Wiki, and you will need a recent
nightly build of Solr 4.0-dev to try it out (just make sure it’s dated after this post).

fq={!frange l=0 u=2.2}log(sum(user_ranking,editor_ranking))

The other interesting use for frange is to trade off memory for speed when doing range queries on any type of single-valued field. For example, one can use frange on a string field provided that there is only one value per field, and that numeric functions are avoided.

For example, here is a filter that only allows authors between martin and rowling, specified using a standard range query:
fq=author_last_name:[martin TO rowling]

And the same filter using a function range query (frange):
fq={!frange l=martin u=rowling}author_last_name

This can lead to significant performance improvements for range queries with many terms between the endpoints, at the cost of memory to hold the un-inverted form of the field in memory (i.e. a FieldCache entry – same as would be used for sorting). If the field in question is already being used for sorting or other function queries, there won’t be any additional memory overhead.

The following chart shows the results of a test of frange queries vs standard range queries on a string field with 200,000 unique values. For example, frange was 14 times faster when executing a range query / range filter that covered 20% of the terms in the field. For narrower ranges that matched less than 5% of the values, the traditional range query performed better.

Of course, Solr 1.4 also contains the new TrieRange functionality that will generally have the best time/space profile for range queries over numeric fields.

• Analyze This! Tips and tricks on getting the Lucene/Solr Analyzer to index and search your content right – On-demand Webinar
• Optimizing Findability – Tech Article
• Solr 1.4 Download
• Solr 1.4 Reference Guide

Nested Queries in Lucene Syntax

To embed a query of another type in a Lucene/Solr query string, simply use the magic field name _query_.  The following example embeds a lucene query type:poems into another lucene query:

text:"roses are red" AND _query_:"type:poems"

Now of course this isn’t too useful on it’s own, but it becomes very powerful in conjunction with the query parser framework and local params which allows us to change the types of queries.  The following example embeds a DisMax query in a normal lucene query:

text:hi  AND  _query_:"{!dismax qf=title pf=title}how now brown cow"

And we can further use parameter defererencing in the local params syntax to make it easier for the front-end to compose the request:

&q=text:hi  AND  _query_:"{!dismax qf=title pf=title v=$qq}
&qq=how now brown cow

Nested Queries in Function Query Syntax

This is the part that was previously broken, and is only fixed/available in Solr 1.4.  You can use query() function to embed any other type of query in a function query, and do computations on the relevancy scores returned by that query.  Some examples from the Solr wiki are here.

Pure Nested Query

There is also a nested query parser plugin that allows one to create pure nested queries.  Is a nested query without any containing query even useful? Surprisingly yes, as it allows further decomposition of query requests.

For example, the following allows an easy way for the client to specify that they want some sort of recency date boost added into the relevancy score, while leaving the exact query type up to the Solr server config (via search handler defaults in solrconfig.xml)

The client query would specify the boost query as $datefunc:

q=how now brown cow&bq={!query v=$datefunc}

And the defaults for the handler in solrconfig.xml would contain the actual definition of datefunc as a function query:

<lst name="defaults">
   <str name="datefunc">{!func}recip(rord(date),1,1000,1000)</str>
   [...]

The same idea could be used to allow a client to switch between complex filters, without having to specify what those filters are.

Without the nested query parser type, it would only be possible to specify the query value in a separate place (via local params v=$param) not the type also.

The Future

An XML Query Parser is on the way via SOLR-839 that will allow expressing arbitrarily complex Lucene queries in XML.  As the number of query parsers grows, the importance of being able to mix, match, and nest them will become increasingly important.   One of the first extensions to the XML query parser should be to hook in nested queries of course!

The subclasses of QParserPlugin show all of the query parsers currently available to Solr.  If you can’t find the query parser you’re looking for, you can create your own and register it via solrconfig.xml!

You might also be interested in:

• Analyze This! Tips and tricks on getting the Lucene/Solr Analyzer to index and search your content right – On-demand Webinar
• Optimizing Findability – Tech Article
• Solr 1.4 Download
• Solr 1.4 Reference Guide