lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Trivial Update of "CommonQueryParameters" by Jan Vogel
Date Fri, 22 Jun 2012 19:44:16 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "CommonQueryParameters" page has been changed by Jan Vogel:
http://wiki.apache.org/solr/CommonQueryParameters?action=diff&rev1=48&rev2=49

  <<TableOfContents>>
  
  <<Anchor(q)>>
+ 
  == q ==
- The '''q''' parameter is normally the main query for the request.
- See [[SolrQuerySyntax|Solr query syntax]] for more information on different types of queries
and syntaxes.
+ The '''q''' parameter is normally the main query for the request. See [[SolrQuerySyntax|Solr
query syntax]] for more information on different types of queries and syntaxes.
  
  <<Anchor(sort)>>
+ 
  == sort ==
+ ||||<style="text-align:center">'''Examples''' ||
+ ||'''sort''' ||'''Meaning''' ||
+ || ||by default, it is the same as `score desc` ||
+ ||`score desc` ||sort from highest score to lowest score ||
+ ||`price asc` ||sort in ascending order of the "price" field ||
+ ||`inStock desc, price asc` ||sort by "inStock" descending, then "price" ascending ||
+ ||`sum(x_f, y_f) desc` ||sort by the sum of x_f and y_f in a descending order ||
  
- ||||'''Examples'''||
- ||'''sort'''||'''Meaning'''||
- || ||by default, it is the same as `score desc`||
- ||`score desc`||sort from highest score to lowest score||
- ||`price asc`||sort in ascending order of the "price" field||
- ||`inStock desc, price asc`||sort by "inStock" descending, then "price" ascending||
- ||`sum(x_f, y_f) desc`|| sort by the sum of x_f and y_f in a descending order||
  
  Sorting can be done on the "score" of the document, or on any {{{multiValued="false" indexed="true"}}}
field provided that field is either non-tokenized (ie: has no Analyzer) or uses an Analyzer
that only produces a single Term (ie: uses the !KeywordTokenizer)
  
@@ -30, +31 @@

  
  NOTE:
  
-    1. A sort ordering must include a field name (or the pseudo-field `score`), followed
by whitespace (escaped as `+` or `%20` in URL strings), followed by a sort direction (`asc`
or `desc`).
+  1. A sort ordering must include a field name (or the pseudo-field `score`), followed by
whitespace (escaped as `+` or `%20` in URL strings), followed by a sort direction (`asc` or
`desc`).
-    1. Multiple sort orderings can be separated by a comma, ie: `sort=<field name>+<direction>[,<field
name>+<direction>]...` 
+  1. Multiple sort orderings can be separated by a comma, ie: `sort=<field name>+<direction>[,<field
name>+<direction>]...`
  
  <<Anchor(start)>>
+ 
  == start ==
- 
  This parameter is used to paginate results from a query.  When specified, it indicates the
'''offset in the complete result set''' for the queries where the set of returned documents
should begin. (i.e. the first record appear in the result set is the offset)
  
  The default value is "`0`".
  
  <<Anchor(rows)>>
+ 
  == rows ==
- 
  This parameter is used to paginate results from a query.  When specified, it indicates the
'''maximum number of documents''' from the complete result set to return to the client for
every request. (You can consider it as the maximum number of result appear in the page)
  
  The default value is "`10`"
  
  <<Anchor(pageDocpageScore)>>
+ 
  == pageDoc and pageScore ==
+ <!> [[Solr4.0]] See https://issues.apache.org/jira/browse/SOLR-1726 If you expect
to be paging deeply into the results (say beyond page 10, assuming rows=10) and you are sorting
by score, you may wish to add the pageDoc and pageScore parameters to your request.  These
two parameters tell Solr (and Lucene) what the last result (Lucene internal docid and score)
of the previous page was, so that when scoring the query for the next set of pages, it can
ignore any results that occur higher than that item.  To get the Lucene internal doc id, you
will need to add [docid] to the &fl list.
  
- <!> [[Solr4.0]] See https://issues.apache.org/jira/browse/SOLR-1726
- If you expect to be paging deeply into the results (say beyond page 10, assuming rows=10)
and you are sorting by score, you may wish to add the pageDoc and pageScore parameters to
your request.  These two parameters tell Solr (and Lucene) what the last result (Lucene internal
docid and score) of the previous page was, so that when scoring the query for the next set
of pages, it can ignore any results that occur higher than that item.  To get the Lucene internal
doc id, you will need to add [docid] to the &fl list.
- 
-    . Example: {{{q=*:*&start=10&pageDoc=5&pageScore=1.345&fl=[docid],score}}}
+  . Example: {{{q=*:*&start=10&pageDoc=5&pageScore=1.345&fl=[docid],score}}}
  
  <<Anchor(fq)>>
+ 
  == fq ==
- 
  "fq" stands for Filter Query.
  
- This parameter can be used to specify a [[SolrQuerySyntax| query]] that can be used to restrict
the super set of documents that can be returned, without influencing score.  It can be very
useful for speeding up complex queries since the queries specified with fq are cached independently
from the main query.
+ This parameter can be used to specify a [[SolrQuerySyntax|query]] that can be used to restrict
the super set of documents that can be returned, without influencing score.  It can be very
useful for speeding up complex queries since the queries specified with fq are cached independently
from the main query. Caching means the same filter is used again for a later query (i.e. there's
a cache hit). See SolrCaching to learn about the caches Solr uses.
- Caching means the same filter is used again for a later query (i.e. there's a cache hit).
- See SolrCaching to learn about the caches Solr uses.
  
- NOTE: 
+ NOTE:
  
-    1. The fq param can be specified multiple times. Documents will only be included in the
result if they are in the intersection of the document sets resulting from each fq.  In the
example below, only documents which have a popularity greater then 10 and have a section of
0 will match. {{{
+  1. The fq param can be specified multiple times. Documents will only be included in the
result if they are in the intersection of the document sets resulting from each fq.  In the
example below, only documents which have a popularity greater then 10 and have a section of
0 will match.
+  {{{
    fq=popularity:[10 TO *]
  & fq=section:0
  }}}
-    1. Filter Queries can be complicated boolean queries, so the above example could also
be written as a single fq with two mandatory clauses...{{{
+  1. Filter Queries can be complicated boolean queries, so the above example could also be
written as a single fq with two mandatory clauses...
+  {{{
-   fq=+popularity:[10 TO *] +section:0   
+   fq=+popularity:[10 TO *] +section:0
  }}}
-    1. The document sets from each filter query are cached independently.  Thus, concerning
the previous examples: use a single fq containing two mandatory clauses if those clauses appear
together often, and use two separate fq params if they are relatively independent.
+  1. The document sets from each filter query are cached independently.  Thus, concerning
the previous examples: use a single fq containing two mandatory clauses if those clauses appear
together often, and use two separate fq params if they are relatively independent.
-    1. As with all parameters: when expressed in a URL, special characters need to be [[SolrQuerySyntax#urlescaping|
properly URL escaped]].
+  1. As with all parameters: when expressed in a URL, special characters need to be [[SolrQuerySyntax#urlescaping|properly
URL escaped]].
  
  === Caching of filters ===
- Each filter query is normally generated and cached independently in the '''filterCache''',
leading to improved request throughput for filters that are likely to be reused.
- Starting with [[Solr3.4]], the [[LocalParams|local param]] '''cache=false''' can be added
at the top-level of any filter query, and cause that filter to not be generated up front and
cached, but instead executed in parallel with the query and all other filters.  This can be
beneficial for filters that will not be reused in other requests (thus avoiding polluting
the filterCache) and for filters that are very expensive to evaluate for every document in
the index.
+ Each filter query is normally generated and cached independently in the '''filterCache''',
leading to improved request throughput for filters that are likely to be reused. Starting
with [[Solr3.4]], the [[LocalParams|local param]] '''cache=false''' can be added at the top-level
of any filter query, and cause that filter to not be generated up front and cached, but instead
executed in parallel with the query and all other filters.  This can be beneficial for filters
that will not be reused in other requests (thus avoiding polluting the filterCache) and for
filters that are very expensive to evaluate for every document in the index.
  
   . Example: {{{q=*:*&fq={!cache=false}inStock:true}}}
   . Example: {{{q=*:*&fq={!frange l=1 u=4 cache=false}sqrt(popularity)}}}
@@ -91, +90 @@

  
   . Example: {{{q=*:*&fq={!frange l=1 u=4 cache=false cost=150}sqrt(popularity)}}}
  
+ <<Anchor(fl)>>
  
- <<Anchor(fl)>>
  == fl ==
- 
  This parameter can be used to specify a set of fields to return, limiting the amount of
information in the response.  When returning the results to the client, only fields in this
list will be included.
  
  The set of fields to be returned can be specified as a space (or comma) separated list of
field names.  The string "`score`" can be used to indicate that the score of each document
for the particular query should be returned as a field, and the string "`*`" can be used to
indicate all stored fields the document has.
+ ||||<style="text-align:center">'''Examples''' ||
+ ||'''Field List''' ||'''Meaning''' ||
+ ||`id name price` ||Only return the "id", "name", and "price" fields ||
+ ||`id,name,price` ||Same as above ||
+ ||`id name, price` ||Same as above ||
+ ||`id score` ||Return the "id" field and the score ||
+ ||`*` ||Return all fields the each document has ||
+ ||`* score` ||Return all fields each document has, along with the score ||
  
  
+ 
- ||||'''Examples'''||
- ||'''Field List'''||'''Meaning'''||
- ||`id name price`||Only return the "id", "name", and "price" fields||
- ||`id,name,price`||Same as above||
- ||`id name, price`||Same as above||
- ||`id score`||Return the "id" field and the score||
- ||`*`||Return all fields the each document has||
- ||`* score`||Return all fields each document has, along with the score||
  
  The default value is "`*`"
  
- <!> [[Solr4.0]]
- In 4.x, the fl parameter supports 'pseudo fields', see https://issues.apache.org/jira/browse/SOLR-2444
+ <!> [[Solr4.0]] In 4.x, the fl parameter supports 'pseudo fields', see https://issues.apache.org/jira/browse/SOLR-2444
  
- In 4.x, you can send fields as many parameters.  For example:
- &fl=id,name,price 
- is the same as:
- &fl=id&fl=name&price
+ In 4.x, you can send fields as many parameters.  For example: &fl=id,name,price  is
the same as: &fl=id&fl=name&price
+ 
+ === glob ===
+ ||'''Example''' ||'''Meaning''' ||
+ ||`id,tag*` ||return id and all fields that start with tag ||
  
  
- === glob ===
+ === functions ===
+ ||'''Example''' ||'''Meaning''' ||
+ ||`id,foo(c)` ||id and a function ||
  
+ 
+ === Transformers ===
+ [[http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/response/transform/DocTransformer.java|Transformers]]
manipulate documents before they are returned.  Standard transformers include:
- ||'''Example'''||'''Meaning'''||
+ ||'''Example''' ||'''Meaning''' ||
- ||`id,tag*`||return id and all fields that start with tag||
+ ||`[docid]` ||the lucene document id (int) ||
+ ||`[shard]` ||the id of the shard that produced the result ||
+ ||`[explain]` ||inline explain info ||
+ ||`[explain style=nl|text|html]` ||explain info with explicit style ||
+ ||`[value v=? t=int|double|float|date]` ||explicit value ||
  
  
  
- === functions ===
- 
- ||'''Example'''||'''Meaning'''||
- ||`id,foo(c)`||id and a function ||
- 
- 
- 
- === Transformers ===
- 
- [[http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/response/transform/DocTransformer.java|Transformers]]
manipulate documents before they are returned.  Standard transformers include:
- 
- ||'''Example'''||'''Meaning'''||
- ||`[docid]`|| the lucene document id (int) ||
- ||`[shard]`|| the id of the shard that produced the result ||
- ||`[explain]`|| inline explain info ||
- ||`[explain style=nl|text|html]`|| explain info with explicit style ||
- ||`[value v=? t=int|double|float|date]`|| explicit value ||
  
  Custom Transformers can be registered in solrconfig.xml
  
  === Field alias ===
+ Any field, function, or transformer can be displayed with a different name in the output
document:
+ ||'''Example''' ||'''Meaning''' ||
+ ||`id,price:crazy_price_field` ||return the stored field 'crazy_price_field' but display
it as 'price' ||
+ ||`id,price:sum(a,b)` ||return price as the sum of fields a+b ||
+ ||`fl=my_alias:field_name`||returns "field_name" but displays it as "my_alias"||
  
- Any field, function, or transformer can be displayed with a different name in the output
document:
- 
- ||'''Example'''||'''Meaning'''||
- ||`id,price:crazy_price_field`||return the stored field 'crazy_price_field' but display
it as 'price' ||
- ||`id,price:sum(a,b)`||return price as the sum of fields a+b ||
  
  
  
  <<Anchor(debugging)>>
+ 
  == Debugging ==
  === debugQuery ===
- 
  If this parameter is present (regardless of its value) then additional debugging information
will be included in the response, including "explain" info for each of the documents returned.
 This debugging info is meant for human consumption... its XML format could change in the
future.
  
  The default behavior is not to include debugging info.
  
  === debug ===
- 
  <!> [[Solr4.0]]
  
  Clients may also specify control over individual parts of debugging output by specifying
{{{debug=}}} with one of four options:
+ 
   * timing -- Provide debug info about timing of components, etc. only
   * query -- Provide debug info about the query only
   * results -- Provide debug info about the results (currently explains)
   * true -- If true, this is the equivalent of &debugQuery=true
  
+ <<Anchor(explainOther)>>
  
- <<Anchor(explainOther)>>
  === explainOther ===
- 
- This parameter allows clients to specify a Lucene query to identify a set of documents.
 If non-blank, the explain info of each document that matches this query, relative to the
''main query'' (specified by the q parameter) will be returned along with the rest of the
debugging information.  This is useful, for instance, for understanding why a particular document
is not in the result set.  For instance, the query http://localhost:8983/solr/select?q=ipod&debug=results&explainOther=id:MA*
(run against <!> [[Solr4.0]]) shows the explanations for the query ipod and also shows
the explanations for all documents that match id:MA* as if the main query were run (ipod)
and produced the documents that the id:MA* query produced.  
+ This parameter allows clients to specify a Lucene query to identify a set of documents.
 If non-blank, the explain info of each document that matches this query, relative to the
''main query'' (specified by the q parameter) will be returned along with the rest of the
debugging information.  This is useful, for instance, for understanding why a particular document
is not in the result set.  For instance, the query http://localhost:8983/solr/select?q=ipod&debug=results&explainOther=id:MA*
(run against <!> [[Solr4.0]]) shows the explanations for the query ipod and also shows
the explanations for all documents that match id:MA* as if the main query were run (ipod)
and produced the documents that the id:MA* query produced.
  
  The default value is blank (i.e. no extra explain info will be returned)
  
  === debug.explain.structured ===
- 
  <!> [[Solr3.2]]
  
  If "true", this parameter tells the !DebugComponent that score Explanations should be returned
as structured data, which the response writer can then output natively.  When "false" the
Explanation information is returned as a (more compact) single string with whitespace used
for indenting to show the nested structure.
  
  The default value is "false"
  
+ <<Anchor(defType)>>
  
- <<Anchor(defType)>>
  == defType ==
- 
- The defType parameter can be used to specify the query parser to use with this request.
 See http://lucene.apache.org/solr/api/org/apache/solr/search/QParserPlugin.html
+ The defType parameter can be used to specify the query parser to use with this request.
 See http://lucene.apache.org/solr/api/org/apache/solr/search/QParserPlugin.html and http://wiki.apache.org/solr/SolrPlugins#head-60a8c7a0663bd05a528899e7719ffe52522a21c2
- and http://wiki.apache.org/solr/SolrPlugins#head-60a8c7a0663bd05a528899e7719ffe52522a21c2
  
  <<Anchor(timeAllowed)>>
+ 
  == timeAllowed ==
  <!> [[Solr1.3]]
  
  The time allowed for a '''search''' to finish.  This value only applies to the search and
not to requests in general.  Time is in milliseconds.  Values <= 0 mean no time restriction.
 Partial results may be returned (if there are any).
-   
+ 
  <<Anchor(omitHeader)>>
+ 
  == omitHeader ==
  Range: {true|false}
  

Mime
View raw message