1

I'm struggling to wrap my brain around local params in solr. When would you actually use them to do things like q.op? How is ?q={!q.op=OR}solr rocks different from ?q=solr rocks&q.op=OR and when would it be useful. The main thing I can think is if you only have access to the q= param via whatever api or lib you are using. Is it mainly for nesting more complex searches, if so, is there an example somewhere in the docs?

It also appears that some params are just inherently different, like {!boost... vs bq/bf, but I still don't see why you couldn't/shouldn't be able to do something like ?q=solr rocks&boost=[some boost thing] if the local params are fairly interchangeable.

Is there something I'm misunderstanding in this process?

horriblyUnpythonic
  • 853
  • 2
  • 14
  • 34

2 Answers2

3

Local parameters are arguments in a Solr request that are specific to a query parameter.

Local parameters provide a way to add meta-data to certain argument types such as query strings. (In Solr documentation, local parameters are sometimes referred to as LocalParams.)

The important part is "certain argument types". This means that it's not only valid for the q parameter.

The examples you've given above can also be used with the fq parameter, for example to use a dismax search query as the fq:

fq={!dismax qf=myfield}solr rocks

Another very useful thing is to be able to tag and exclude fq parameters when creating facets - i.e. allow you to filter the result set without filtering the documents used for the facets:

q=mainquery&fq=status:public&fq={!tag=dt}doctype:pdf&facet=true&facet.field={!ex=dt}doctype

Here the {!tag} and {!ex} parameters change something for that specific parameter and not for the whole query (which a query parameter would do).

It's also useful when decoupling the parameters with the parameter dereferencing support, which means that you can lock the parameter itself (and its argument) through the use of invariant for the query parameter in solrconfig, then use the new query argument to send the actual user supplied string in to the query:

q={!type=dismax qf=myfield v=$qq}&qq=solr rocks

In this case you can lock the q parameter to whatever given above, then only supply the query string through qq.

There are many, many other examples of using localparams to change how one specific query argument behaves, but hopefully this will give you an idea of why and how to use them.

Community
  • 1
  • 1
MatsLindh
  • 49,529
  • 4
  • 53
  • 84
1

In the past Local Parameters and dereferencing were used by some applications to keep the query simpler and define certain values in the solrconfig.xml. This allows you to update the behavior of an application by just updating the values on the server (for example to configure the boost values of the fields used in searches) without having to update the client application(s). Applications using Blacklight are an example of this.

This is still technically possible, but for security reasons the use of Local Parameters is restricted in recent versions of Solr.

Starting a query string with local parameters {!myparser …​} is used to switch from one query parser to another, and is intended for use by Solr system developers, not end users doing searches. To reduce negative side-effects of unintended hack-ability, Solr now limits the cases when local parameters will be parsed to only contexts in which the default parser is "lucene" or "func".

Hector Correa
  • 26,290
  • 8
  • 57
  • 73