You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2017/05/06 03:43:03 UTC
lucene-solr:jira/solr-10290: SOLR-10296: conversion, letter F, part 1
Repository: lucene-solr
Updated Branches:
refs/heads/jira/solr-10290 c0cc260ce -> ccf5dd28a
SOLR-10296: conversion, letter F, part 1
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/ccf5dd28
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/ccf5dd28
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/ccf5dd28
Branch: refs/heads/jira/solr-10290
Commit: ccf5dd28af555a35b3938ad8948afa6822887fbc
Parents: c0cc260
Author: Cassandra Targett <ct...@apache.org>
Authored: Fri May 5 22:42:37 2017 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Fri May 5 22:42:37 2017 -0500
----------------------------------------------------------------------
solr/solr-ref-guide/src/codec-factory.adoc | 2 +-
solr/solr-ref-guide/src/faceting.adoc | 165 ++++++++++---------
.../src/field-properties-by-use-case.adoc | 18 +-
.../field-type-definitions-and-properties.adoc | 39 +++--
.../src/field-types-included-with-solr.adoc | 4 +-
solr/solr-ref-guide/src/files-screen.adoc | 6 +-
6 files changed, 116 insertions(+), 118 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/ccf5dd28/solr/solr-ref-guide/src/codec-factory.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/codec-factory.adoc b/solr/solr-ref-guide/src/codec-factory.adoc
index f4326eb..2e80788 100644
--- a/solr/solr-ref-guide/src/codec-factory.adoc
+++ b/solr/solr-ref-guide/src/codec-factory.adoc
@@ -6,7 +6,7 @@ A `codecFactory` can be specified in `solrconfig.xml` to determine which Lucene
If not specified, Lucene's default codec is implicitly used, but a {solr-javadocs}/solr-core/org/apache/solr/core/SchemaCodecFactory.html[`solr.SchemaCodecFactory`] is also available which supports 2 key features:
-* Schema based per-fieldtype configuration for `docValuesFormat` and `postingsFormat` - see the <<field-type-definitions-and-properties.adoc#FieldTypeDefinitionsandProperties-GeneralProperties,Field Type Definitions and Properties>> section for more details.
+* Schema based per-fieldtype configuration for `docValuesFormat` and `postingsFormat` - see the <<field-type-definitions-and-properties.adoc#field-type-properties,Field Type Properties>> section for more details.
* A `compressionMode` option:
** `BEST_SPEED` (default) is optimized for search speed performance
** `BEST_COMPRESSION` is optimized for disk space usage
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/ccf5dd28/solr/solr-ref-guide/src/faceting.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/faceting.adoc b/solr/solr-ref-guide/src/faceting.adoc
index 8e978f7..8c979cd 100644
--- a/solr/solr-ref-guide/src/faceting.adoc
+++ b/solr/solr-ref-guide/src/faceting.adoc
@@ -3,31 +3,26 @@
:page-permalink: faceting.html
:page-children: blockjoin-faceting
-As described in the section <<overview-of-searching-in-solr.adoc#overview-of-searching-in-solr,Overview of Searching in Solr>>, faceting is the arrangement of search results into categories based on indexed terms. Searchers are presented with the indexed terms, along with numerical counts of how many matching documents were found were each term. Faceting makes it easy for users to explore search results, narrowing in on exactly the results they are looking for.
+Faceting is the arrangement of search results into categories based on indexed terms.
+
+Searchers are presented with the indexed terms, along with numerical counts of how many matching documents were found were each term. Faceting makes it easy for users to explore search results, narrowing in on exactly the results they are looking for.
[[Faceting-GeneralParameters]]
== General Parameters
-The table below summarizes the general parameters for controlling faceting.
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Parameter |Description
-|<<Faceting-ThefacetParameter,facet>> |If set to true, enables faceting.
-|<<Faceting-Thefacet.queryParameter,facet.query>> |Specifies a Lucene query to generate a facet count.
-|===
-
-These parameters are described in the sections below.
+There are two general parameters for controlling faceting.
[[Faceting-ThefacetParameter]]
=== The `facet` Parameter
-If set to "true," this parameter enables facet counts in the query response. If set to "false" to a blank or missing value, this parameter disables faceting. None of the other parameters listed below will have any effect unless this parameter is set to "true." The default value is blank.
+If set to *true*, this parameter enables facet counts in the query response. If set to *false*, a blank or missing value, this parameter disables faceting. None of the other parameters listed below will have any effect unless this parameter is set to *true*. The default value is blank (false).
[[Faceting-Thefacet.queryParameter]]
=== The `facet.query` Parameter
-This parameter allows you to specify an arbitrary query in the Lucene default syntax to generate a facet count. By default, Solr's faceting feature automatically determines the unique terms for a field and returns a count for each of those terms. Using `facet.query`, you can override this default behavior and select exactly which terms or expressions you would like to see counted. In a typical implementation of faceting, you will specify a number of `facet.query` parameters. This parameter can be particularly useful for numeric-range-based facets or prefix-based facets.
+This parameter allows you to specify an arbitrary query in the Lucene default syntax to generate a facet count.
+
+By default, Solr's faceting feature automatically determines the unique terms for a field and returns a count for each of those terms. Using `facet.query`, you can override this default behavior and select exactly which terms or expressions you would like to see counted. In a typical implementation of faceting, you will specify a number of `facet.query` parameters. This parameter can be particularly useful for numeric-range-based facets or prefix-based facets.
You can set the `facet.query` parameter multiple times to indicate that multiple queries should be used as separate facet constraints.
@@ -40,11 +35,13 @@ To use facet queries in a syntax other than the default syntax, prefix the facet
Several parameters can be used to trigger faceting based on the indexed terms in a field.
-When using this parameter, it is important to remember that "term" is a very specific concept in Lucene: it relates to the literal field/value pairs that are indexed after any analysis occurs. For text fields that include stemming, lowercasing, or word splitting, the resulting terms may not be what you expect. If you want Solr to perform both analysis (for searching) and faceting on the full literal strings, use the `copyField` directive in your Schema to create two versions of the field: one Text and one String. Make sure both are `indexed="true"`. (For more information about the `copyField` directive, see <<documents-fields-and-schema-design.adoc#documents-fields-and-schema-design,Documents, Fields, and Schema Design>>.)
+When using these parameters, it is important to remember that "term" is a very specific concept in Lucene: it relates to the literal field/value pairs that are indexed after any analysis occurs. For text fields that include stemming, lowercasing, or word splitting, the resulting terms may not be what you expect.
+
+If you want Solr to perform both analysis (for searching) and faceting on the full literal strings, use the `copyField` directive in your Schema to create two versions of the field: one Text and one String. Make sure both are `indexed="true"`. (For more information about the `copyField` directive, see <<documents-fields-and-schema-design.adoc#documents-fields-and-schema-design,Documents, Fields, and Schema Design>>.)
The table below summarizes Solr's field value faceting parameters.
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|<<Faceting-Thefacet.fieldParameter,facet.field>> |Identifies a field to be treated as a facet.
@@ -74,9 +71,7 @@ The `facet.field` parameter identifies a field that should be treated as a facet
[IMPORTANT]
====
-
If you do not set this parameter to at least one field in the schema, none of the other parameters described in this section will have any effect.
-
====
[[Faceting-Thefacet.prefixParameter]]
@@ -105,12 +100,10 @@ This parameter can be specified on a per-field basis with the syntax of `f.<fiel
This parameter determines the ordering of the facet field constraints.
-[width="100%",cols="50%,50%",options="header",]
-|===
-|`facet.sort` Setting |Results
-|count |Sort the constraints by count (highest count first).
-|index |Return the constraints sorted in their index order (lexicographic by indexed term). For terms in the ASCII range, this will be alphabetically sorted.
-|===
+There are two options for this parameter.
+
+count:: Sort the constraints by count (highest count first).
+index:: Return the constraints sorted in their index order (lexicographic by indexed term). For terms in the ASCII range, this will be alphabetically sorted.
The default is `count` if `facet.limit` is greater than 0, otherwise, the default is `index`.
@@ -157,15 +150,23 @@ This parameter can be specified on a per-field basis with the syntax of `f.<fiel
The facet.method parameter selects the type of algorithm or method Solr should use when faceting a field.
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Setting |Results
-|enum |Enumerates all terms in a field, calculating the set intersection of documents that match the term with documents that match the query. This method is recommended for faceting multi-valued fields that have only a few distinct values. The average number of values per document does not matter. For example, faceting on a field with U.S. States such as `Alabama, Alaska, ... Wyoming` would lead to fifty cached filters which would be used over and over again. The `filterCache` should be large enough to hold all the cached filters.
-|fc |Calculates facet counts by iterating over documents that match the query and summing the terms that appear in each document. This is currently implemented using an `UnInvertedField` cache if the field either is multi-valued or is tokenized (according to `FieldType.isTokened()`). Each document is looked up in the cache to see what terms/values it contains, and a tally is incremented for each value. This method is excellent for situations where the number of indexed values for the field is high, but the number of values per document is low. For multi-valued fields, a hybrid approach is used that uses term filters from the `filterCache` for terms that match many documents. The letters `fc` stand for field cache.
-|fcs |Per-segment field faceting for single-valued string fields. Enable with `facet.method=fcs` and control the number of threads used with the `threads` local parameter. This parameter allows faceting to be faster in the presence of rapid index changes.
-|===
+The following methods are available.
+
+enum:: Enumerates all terms in a field, calculating the set intersection of documents that match the term with documents that match the query.
++
+This method is recommended for faceting multi-valued fields that have only a few distinct values. The average number of values per document does not matter.
++
+For example, faceting on a field with U.S. States such as `Alabama, Alaska, ... Wyoming` would lead to fifty cached filters which would be used over and over again. The `filterCache` should be large enough to hold all the cached filters.
-The default value is `fc` (except for fields using the `BoolField` field type and when facet.exists=true is requsted) since it tends to use less memory and is faster when a field has many unique terms in the index.
+fc:: Calculates facet counts by iterating over documents that match the query and summing the terms that appear in each document.
++
+This is currently implemented using an `UnInvertedField` cache if the field either is multi-valued or is tokenized (according to `FieldType.isTokened()`). Each document is looked up in the cache to see what terms/values it contains, and a tally is incremented for each value.
++
+This method is excellent for situations where the number of indexed values for the field is high, but the number of values per document is low. For multi-valued fields, a hybrid approach is used that uses term filters from the `filterCache` for terms that match many documents. The letters `fc` stand for field cache.
+
+fcs:: Per-segment field faceting for single-valued string fields. Enable with `facet.method=fcs` and control the number of threads used with the `threads` local parameter. This parameter allows faceting to be faster in the presence of rapid index changes.
+
+The default value is `fc` (except for fields using the `BoolField` field type and when `facet.exists=true` is requested) since it tends to use less memory and is faster when a field has many unique terms in the index.
This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.method`.
@@ -183,7 +184,7 @@ This parameter can be specified on a per-field basis with the syntax of `f.<fiel
[[Faceting-Thefacet.existsParameter]]
=== The `facet.exists` Parameter
-To cap facet counts by 1 specify facet.exists=true. It can be used with facet.method=enum or when it's omitted. It can be used only on non-trie fields i.e. strings. It may speed up facet counting on large indices and/or high-cardinality facet values..
+To cap facet counts by 1, specify `facet.exists=true`. It can be used with `facet.method=enum` or when it's omitted. It can be used only on non-trie fields (such as strings). It may speed up facet counting on large indices and/or high-cardinality facet values..
This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.exists` or via local parameter` facet.field={!facet.method=enum facet.exists=true}size`.
@@ -209,7 +210,7 @@ This param will cause loading the underlying fields used in faceting to be execu
You can use Range Faceting on any date field or any numeric field that supports range queries. This is particularly useful for stitching together a series of range queries (as facet by query) for things like prices. As of Solr 3.1, Range Faceting is preferred over <<Faceting-DateFacetingParameters,Date Faceting>> (described below).
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|<<Faceting-Thefacet.rangeParameter,facet.range>> |Specifies the field to facet by range.
@@ -261,7 +262,9 @@ The span of each range expressed as a value to be added to the lower bound. For
[[Faceting-Thefacet.range.hardendParameter]]
=== The `facet.range.hardend` Parameter
-The `facet.range.hardend` parameter is a Boolean parameter that specifies how Solr should handle cases where the `facet.range.gap` does not divide evenly between `facet.range.start` and `facet.range.end`. If **true**, the last range constraint will have the `facet.range.end` value as an upper bound. If **false**, the last range will have the smallest possible upper bound greater then `facet.range.end` such that the range is the exact width of the specified range gap. The default value for this parameter is false.
+The `facet.range.hardend` parameter is a Boolean parameter that specifies how Solr should handle cases where the `facet.range.gap` does not divide evenly between `facet.range.start` and `facet.range.end`.
+
+If *true*, the last range constraint will have the `facet.range.end` value as an upper bound. If *false*, the last range will have the smallest possible upper bound greater then `facet.range.end` such that the range is the exact width of the specified range gap. The default value for this parameter is false.
This parameter can be specified on a per field basis with the syntax `f.<fieldname>.facet.range.hardend`.
@@ -270,7 +273,7 @@ This parameter can be specified on a per field basis with the syntax `f.<fieldna
By default, the ranges used to compute range faceting between `facet.range.start` and `facet.range.end` are inclusive of their lower bounds and exclusive of the upper bounds. The "before" range defined with the `facet.range.other` parameter is exclusive and the "after" range is inclusive. This default, equivalent to "lower" below, will not result in double counting at the boundaries. You can use the `facet.range.include` parameter to modify this behavior using the following options:
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Option |Description
|lower |All gap-based ranges include their lower bound.
@@ -284,9 +287,7 @@ You can specify this parameter on a per field basis with the syntax of `f.<field
[NOTE]
====
-
To ensure you avoid double-counting, do not choose both `lower` and `upper`, do not choose `outer`, and do not choose `all`.
-
====
[[Faceting-Thefacet.range.otherParameter]]
@@ -311,17 +312,14 @@ This parameter can be specified on a per field basis with the syntax of `f.<fiel
The `facet.range.method` parameter selects the type of algorithm or method Solr should use for range faceting. Both methods produce the same results, but performance may vary.
-[cols=",",options="header",]
-|===
-|Method |Description
-|filter |This method generates the ranges based on other facet.range parameters, and for each of them executes a filter that later intersects with the main query resultset to get the count. It will make use of the filterCache, so it will benefit of a cache large enough to contain all ranges.
-|dv |This method iterates the documents that match the main query, and for each of them finds the correct range for the value. This method will make use of <<docvalues.adoc#docvalues,docValues>> (if enabled for the field) or fieldCache. "dv" method is not supported for field type DateRangeField or when using <<result-grouping.adoc#result-grouping,group.facets>>.
-|===
+filter:: This method generates the ranges based on other facet.range parameters, and for each of them executes a filter that later intersects with the main query resultset to get the count. It will make use of the filterCache, so it will benefit of a cache large enough to contain all ranges.
+
+dv:: This method iterates the documents that match the main query, and for each of them finds the correct range for the value. This method will make use of <<docvalues.adoc#docvalues,docValues>> (if enabled for the field) or fieldCache. The `dv` method is not supported for field type DateRangeField or when using <<result-grouping.adoc#result-grouping,group.facets>>.
Default value for this parameter is "filter".
[[Faceting-Thefacet.mincountParameterinRangeFaceting]]
-=== The facet.mincount Parameter in Range Faceting
+=== The `facet.mincount` Parameter in Range Faceting
The `facet.mincount` parameter, the same one as used in field faceting is also applied to range faceting. When used, no ranges with a count below the minimum will be included in the response.
@@ -356,7 +354,7 @@ The `facet.pivot.mincount` parameter defines the minimum number of documents tha
Using the "`bin/solr -e techproducts`" example, A query URL like this one will return the data below, with the pivot faceting results found in the section "facet_pivot":
-[source,java]
+[source]
----
http://localhost:8983/solr/techproducts/select?q=*:*&facet.pivot=cat,popularity,inStock
&facet.pivot=popularity,cat&facet=true&facet.field=cat&facet.limit=5
@@ -365,7 +363,7 @@ http://localhost:8983/solr/techproducts/select?q=*:*&facet.pivot=cat,popularity,
[source,json]
----
- "facet_counts":{
+{ "facet_counts":{
"facet_queries":{},
"facet_fields":{
"cat":[
@@ -388,8 +386,8 @@ http://localhost:8983/solr/techproducts/select?q=*:*&facet.pivot=cat,popularity,
"pivot":[{
"field":"inStock",
"value":true,
- "count":5}]},
-...
+ "count":5}]}]
+}]}}}
----
[[Faceting-CombiningStatsComponentWithPivots]]
@@ -399,7 +397,7 @@ In addition to some of the <<Faceting-LocalParametersforFaceting,general local p
In the example below, two different (overlapping) sets of statistics are computed for each of the facet.pivot result hierarchies:
-[source,java]
+[source]
----
stats=true
stats.field={!tag=piv1,piv2 min=true max=true}price
@@ -411,9 +409,9 @@ facet.pivot={!stats=piv2}manu,inStock
Results:
-[source,java]
+[source,json]
----
-"facet_pivot":{
+{"facet_pivot":{
"cat,inStock":[{
"field":"cat",
"value":"electronics",
@@ -452,7 +450,7 @@ Results:
"stats":{
"stats_fields":{
"price":{
- ...
+ "..."
"manu,inStock":[{
"field":"manu",
"value":"inc",
@@ -479,7 +477,7 @@ Results:
"max":479.95001220703125},
"popularity":{
"mean":7.0}}}}],
- ...
+ "..."}]}}}}]}]}}
----
[[Faceting-CombiningFacetQueriesAndFacetRangesWithPivotFacets]]
@@ -489,7 +487,7 @@ A `query` local parameter can be used with `facet.pivot` to refer to `facet.quer
In the example below, two query facets are computed for h of the `facet.pivot` result hierarchies:
-[source,java]
+[source]
----
facet=true
facet.query={!tag=q1}manufacturedate_dt:[2006-01-01T00:00:00Z TO NOW]
@@ -497,9 +495,9 @@ facet.query={!tag=q1}price:[0 TO 100]
facet.pivot={!query=q1}cat,inStock
----
-[source,java]
+[source,json]
----
- "facet_counts": {
+{"facet_counts": {
"facet_queries": {
"{!tag=q1}manufacturedate_dt:[2006-01-01T00:00:00Z TO NOW]": 9,
"{!tag=q1}price:[0 TO 100]": 7
@@ -529,12 +527,12 @@ facet.pivot={!query=q1}cat,inStock
"{!tag=q1}price:[0 TO 100]": 2
}
},
- ...
+ "..."]}]}}}
----
In a similar way, in the example below, two range facets are computed for each of the `facet.pivot` result hierarchies:
-[source,java]
+[source]
----
facet=true
facet.range={!tag=r1}manufacturedate_dt
@@ -544,9 +542,9 @@ facet.range.gap=+1YEAR
facet.pivot={!range=r1}cat,inStock
----
-[source,java]
+[source,json]
----
- "facet_counts":{
+{"facet_counts":{
"facet_queries":{},
"facet_fields":{},
"facet_dates":{},
@@ -606,7 +604,7 @@ facet.pivot={!range=r1}cat,inStock
"gap":"+1YEAR",
"start":"2006-01-01T00:00:00Z",
"end":"2015-01-01T00:00:00Z"}}},
- ...
+ "..."]}]}}}
----
[[Faceting-AdditionalPivotParameters]]
@@ -614,25 +612,22 @@ facet.pivot={!range=r1}cat,inStock
Although `facet.pivot.mincount` deviates in name from the `facet.mincount` parameter used by field faceting, many other Field faceting parameters described above can also be used with pivot faceting:
-* ` facet.limit `
-* ` facet.offset `
+* `facet.limit`
+* `facet.offset`
* `facet.sort` <<Faceting-Thefacet.sortParameter,The facet.sort Parameter>>
-* ` facet.overrequest.count `
-* ` facet.overrequest.ratio `
+* `facet.overrequest.count`
+* `facet.overrequest.ratio`
[[Faceting-IntervalFaceting]]
== Interval Faceting
Another supported form of faceting is interval faceting. This sounds similar to range faceting, but the functionality is really closer to doing facet queries with range queries. Interval faceting allows you to set variable intervals and count the number of documents that have values within those intervals in the specified field.
-Even though the same functionality can be achieved by using a facet query with range queries, the implementation of these two methods is very different and will provide different performance depending on the context. If you are concerned about the performance of your searches you should test with both options. Interval faceting tends to be better with multiple intervals for the same fields, while facet query tend to be better in environments where filter cache is more effective (static indexes for example). This method will use <<docvalues.adoc#docvalues,docValues>> if they are enabled for the field, will use fieldCache otherwise.
+Even though the same functionality can be achieved by using a facet query with range queries, the implementation of these two methods is very different and will provide different performance depending on the context.
-[width="100%",cols="50%,50%",options="header",]
-|===
-|*Name* |*What it does*
-|<<Faceting-Thefacet.intervalparameter,facet.interval>> |Specifies the field to facet by interval.
-|<<Faceting-Thefacet.interval.setparameter,facet.interval.set>> |Sets the intervals for the field.
-|===
+If you are concerned about the performance of your searches you should test with both options. Interval faceting tends to be better with multiple intervals for the same fields, while facet query tend to be better in environments where filter cache is more effective (static indexes for example).
+
+This method will use <<docvalues.adoc#docvalues,docValues>> if they are enabled for the field, will use fieldCache otherwise.
[[Faceting-Thefacet.intervalparameter]]
=== The `facet.interval` parameter
@@ -646,9 +641,9 @@ This parameter Indicates the field where interval faceting must be applied. It c
This parameter is used to set the intervals for the field, it can be specified multiple times to indicate multiple intervals. This parameter is global, which means that it will be used for all fields indicated with `facet.interval` unless there is an override for a specific field. To override this parameter on a specific field you can use: `f.<fieldname>.facet.interval.set`, for example:
-....
+[source]
f.price.facet.interval.set=[0,10]&f.price.facet.interval.set=(10,100]
-....
+
[[Faceting-IntervalSyntax]]
=== Interval Syntax
@@ -661,16 +656,22 @@ For example:
* [1,10) -> will include values greater or equal to 1 and lower than 10
* [1,10] -> will include values greater or equal to 1 and lower or equal to 10
-The initial and end values cannot be empty. If the interval needs to be unbounded, the special character '*' can be used for both, start and end limit. When using '*', '(' and '[', and ')' and ']' will be treated equal. [*,*] will include all documents with a value in the field. The interval limits may be strings but there is no need to add quotes. All the text until the comma will be treated as the start limit, and the text after that will be the end limit. For example: [Buenos Aires,New York]. Keep in mind that a string-like comparison will be done to match documents in string intervals (case-sensitive). The comparator can't be changed.
+The initial and end values cannot be empty. If the interval needs to be unbounded, the special character `*` can be used for both, start and end limit.
+
+When using `\*`, `(` and `[`, and `)` and `]` will be treated equal. `[*,*]` will include all documents with a value in the field.
+
+The interval limits may be strings but there is no need to add quotes. All the text until the comma will be treated as the start limit, and the text after that will be the end limit. For example: `[Buenos Aires,New York]`. Keep in mind that a string-like comparison will be done to match documents in string intervals (case-sensitive). The comparator can't be changed.
+
+Commas, brackets and square brackets can be escaped by using `\` in front of them. Whitespaces before and after the values will be omitted.
-Commas, brackets and square brackets can be escaped by using '\' in front of them. Whitespaces before and after the values will be omitted. The start limit can't be grater than the end limit. Equal limits are allowed, this allows you to indicate the specific values that you want to count, like [A,A], [B,B] and [C,Z].
+The start limit can't be grater than the end limit. Equal limits are allowed, this allows you to indicate the specific values that you want to count, like `[A,A]`, `[B,B]` and `[C,Z]`.
Interval faceting supports output key replacement described below. Output keys can be replaced in both the `facet.interval parameter` and in the `facet.interval.set parameter`. For example:
-[source,java]
+[source]
----
-&facet.interval={!key=popularity}some_field
-&facet.interval.set={!key=bad}[0,5]
+&facet.interval={!key=popularity}some_field
+&facet.interval.set={!key=bad}[0,5]
&facet.interval.set={!key=good}[5,*]
&facet=true
----
@@ -693,7 +694,7 @@ Because everything is already constrained by the filter `doctype:pdf`, the `face
To implement a multi-select facet for doctype, a GUI may want to still display the other doctype values and their associated counts, as if the http://doctypepdf[`doctype:pdf`] constraint had not yet been applied. For example:
-[source,java]
+[source]
----
=== Document Type ===
[ ] Word (42)
@@ -718,11 +719,11 @@ To change the output key for a faceting command, specify a new name with the `ke
The parameter setting above causes the field facet results for the "doctype" field to be returned using the key "mylabel" rather than "doctype" in the response. This can be helpful when faceting on the same field multiple times with different exclusions.
[[Faceting-Limitingfacetwithcertainterms]]
-=== Limiting facet with certain terms
+=== Limiting Facet with Certain Terms
To limit field facet with certain terms specify them comma separated with `terms` local parameter. Commas and quotes in terms can be escaped with backslash, as in `\,`. In this case facet is calculated on a way similar to `facet.method=enum` , but ignores `facet.enum.cache.minDf`. For example:
-` facet.field={!terms='alfa,betta,with\,with\',with space'}symbol `
+`facet.field={!terms='alfa,betta,with\,with\',with space'}symbol`
[[Faceting-RelatedTopics]]
== Related Topics
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/ccf5dd28/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/field-properties-by-use-case.adoc b/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
index 90ee877..d14722c 100644
--- a/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
+++ b/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
@@ -4,22 +4,16 @@
Here is a summary of common use cases, and the attributes the fields or field types should have to support the case. An entry of true or false in the table indicates that the option must be set to the given value for the use case to function correctly. If no entry is provided, the setting of that attribute has no impact on the case.
-[width="100%",cols="16%,12%,12%,12%,12%,12%,12%,12%",options="header",]
+[width="100%",options="header",]
|===
|Use Case |indexed |stored |multiValued |omitNorms |termVectors |termPositions |docValues
|search within field |true | | | | | |
-|retrieve contents | |true^8^ | | | | |true^8^
+|retrieve contents | |truefootnoteref:[8,Stored content will be used by default, but docValues can alternatively be used. See <<docvalues.adoc#docvalues,DocValues>>] | | | | |truefootnoteref:[8]
|use as unique key |true | |false | | | |
-|sort on field |true^7^ | |false |true ^1^ | | |true^7^
-|highlighting |true ^4^ |true | | |true^2^ |true ^3^ |
-|faceting ^5^ |true^7^ | | | | | |true^7^
+|sort on field |truefootnoteref:[7,For most field types, either `indexed` or `docValues` must be true, but both are not required. <<docvalues.adoc#docvalues,DocValues>> can be more efficient in many cases. For `Int/Long/Float/Double/DatePointFields`, `docValues=true` is required.] | |false |truefootnoteref:[1,Recommended but not necessary.] | | |truefootnoteref:[7]
+|highlighting |truefootnoteref:[4,A tokenizer must be defined for the field, but it doesn't need to be indexed.] |true | | |truefootnoteref:[2,Will be used if present, but not necessary.] |truefootnoteref:[3,(if termVectors=true)] |
+|facetingfootnoteref:[5,Described in <<understanding-analyzers-tokenizers-and-filters.adoc#understanding-analyzers-tokenizers-and-filters,Understanding Analyzers, Tokenizers, and Filters>>.] |truefootnoteref:[7] | | | | | |truefootnoteref:[7]
|add multiple values, maintaining order | | |true | | | |
|field length affects doc score | | | |false | | |
-|MoreLikeThis ^5^ | | | | |true ^6^ | |
+|MoreLikeThisfootnoteref:[5] | | | | |truefootnoteref:[6,Term vectors are not mandatory here. If not true, then a stored field is analyzed. So term vectors are recommended, but only required if `stored=false`.] | |
|===
-
-Notes:
-
-^1^ Recommended but not necessary. ^2^ Will be used if present, but not necessary. ^3^ (if termVectors=true) ^4^ A tokenizer must be defined for the field, but it doesn't need to be indexed. ^5^ Described in <<understanding-analyzers-tokenizers-and-filters.adoc#understanding-analyzers-tokenizers-and-filters,Understanding Analyzers, Tokenizers, and Filters>>. ^6^ Term vectors are not mandatory here. If not true, then a stored field is analyzed. So term vectors are recommended, but only required if `stored=false`.^7^ For most field types, either `indexed` or `docValues` must be true, but both are not required. <<docvalues.adoc#docvalues,DocValues>> can be more efficient in many cases. For `[Int/Long/Float/Double/Date]PointFields`, `docValues=true` is required.
-
-^8^ Stored content will be used by default, but docValues can alternatively be used. See <<docvalues.adoc#docvalues,DocValues>>.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/ccf5dd28/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
index 7f6efc6..45838ac 100644
--- a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
+++ b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
@@ -2,11 +2,13 @@
:page-shortname: field-type-definitions-and-properties
:page-permalink: field-type-definitions-and-properties.html
+A field type defines the analysis that will occur on a field when documents are indexed or queries are sent to the index.
+
A field type definition can include four types of information:
-* The name of the field type (mandatory)
-* An implementation class name (mandatory)
-* If the field type is `TextField`, a description of the field analysis for the field type
+* The name of the field type (mandatory).
+* An implementation class name (mandatory).
+* If the field type is `TextField`, a description of the field analysis for the field type.
* Field type properties - depending on the implementation class, some properties may be mandatory.
[[FieldTypeDefinitionsandProperties-FieldTypeDefinitionsinschema.xml]]
@@ -16,8 +18,8 @@ Field types are defined in `schema.xml`. Each field type is defined between `fie
[source,xml]
----
-<fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
- <analyzer type="index">
+<fieldType name="text_general" class="solr.TextField" positionIncrementGap="100"> <1>
+ <analyzer type="index"> <2>
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
<!-- in this example, we will only use synonyms at query time
@@ -34,7 +36,8 @@ Field types are defined in `schema.xml`. Each field type is defined between `fie
</fieldType>
----
-The first line in the example above contains the field type name, `text_general`, and the name of the implementing class, `solr.TextField`. The rest of the definition is about field analysis, described in <<understanding-analyzers-tokenizers-and-filters.adoc#understanding-analyzers-tokenizers-and-filters,Understanding Analyzers, Tokenizers, and Filters>>.
+<1> The first line in the example above contains the field type name, `text_general`, and the name of the implementing class, `solr.TextField`.
+<2> The rest of the definition is about field analysis, described in <<understanding-analyzers-tokenizers-and-filters.adoc#understanding-analyzers-tokenizers-and-filters,Understanding Analyzers, Tokenizers, and Filters>>.
The implementing class is responsible for making sure the field is handled correctly. In the class names in `schema.xml`, the string `solr` is shorthand for `org.apache.solr.schema` or `org.apache.solr.analysis`. Therefore, `solr.TextField` is really `org.apache.solr.schema.TextField.`.
@@ -52,37 +55,35 @@ The field type `class` determines most of the behavior of a field type, but opti
The properties that can be specified for a given field type fall into three major categories:
* Properties specific to the field type's class.
-* <<FieldTypeDefinitionsandProperties-GeneralProperties,General Properties>> Solr supports for any field type.
-* <<FieldTypeDefinitionsandProperties-FieldDefaultProperties,Field Default Properties>> that can be specified on the field type that will be inherited by fields that use this type instead of the default behavior.
+* <<General Properties>> Solr supports for any field type.
+* <<Field Default Properties>> that can be specified on the field type that will be inherited by fields that use this type instead of the default behavior.
-[[FieldTypeDefinitionsandProperties-GeneralProperties]]
=== General Properties
-[width="100%",cols="34%,33%,33%",options="header",]
+[width="100%",options="header",]
|===
|Property |Description |Values
|name |The name of the fieldType. This value gets used in field definitions, in the "type" attribute. It is strongly recommended that names consist of alphanumeric or underscore characters only and not start with a digit. This is not currently strictly enforced. |
-|class |The class name that gets used to store and index the data for this type. Note that you may prefix included class names with "solr." and Solr will automatically figure out which packages to search for the class - so "solr.TextField" will work. If you are using a third-party class, you will probably need to have a fully qualified class name. The fully qualified equivalent for "solr.TextField" is "org.apache.solr.schema.TextField". |
+|class |The class name that gets used to store and index the data for this type. Note that you may prefix included class names with "solr." and Solr will automatically figure out which packages to search for the class - so `solr.TextField` will work. If you are using a third-party class, you will probably need to have a fully qualified class name. The fully qualified equivalent for `solr.TextField` is `org.apache.solr.schema.TextField`. |
|positionIncrementGap |For multivalued fields, specifies a distance between multiple values, which prevents spurious phrase matches |integer
|autoGeneratePhraseQueries |For text fields. If true, Solr automatically generates phrase queries for adjacent terms. If false, terms must be enclosed in double-quotes to be treated as phrases. |true or false
-|enableGraphQueries |For text fields, applicable when querying with https://cwiki.apache.org/confluence/display/solr/The+Standard+Query+Parser#TheStandardQueryParser-StandardQueryParserParameters[`sow=false`]. Use `true` (the default) for field types with query analyzers including graph-aware filters, e.g. <<filter-descriptions.adoc#FilterDescriptions-SynonymGraphFilter,Synonym Graph Filter>> and <<filter-descriptions.adoc#FilterDescriptions-WordDelimiterGraphFilter,Word Delimiter Graph Filter>>. Use `false` for field types with query analyzers including filters that can match docs when some tokens are missing, e.g. <<filter-descriptions.adoc#FilterDescriptions-ShingleFilter,Shingle Filter>>. |true or false
+|enableGraphQueries |For text fields, applicable when querying with <<the-standard-query-parser.adoc#TheStandardQueryParser-StandardQueryParserParameters,`sow=false`>>. Use `true` (the default) for field types with query analyzers including graph-aware filters, e.g. <<filter-descriptions.adoc#FilterDescriptions-SynonymGraphFilter,Synonym Graph Filter>> and <<filter-descriptions.adoc#FilterDescriptions-WordDelimiterGraphFilter,Word Delimiter Graph Filter>>. Use `false` for field types with query analyzers including filters that can match docs when some tokens are missing, e.g., <<filter-descriptions.adoc#FilterDescriptions-ShingleFilter,Shingle Filter>>. |true or false
|[[FieldTypeDefinitionsandProperties-docValuesFormat]]docValuesFormat |Defines a custom `DocValuesFormat` to use for fields of this type. This requires that a schema-aware codec, such as the `SchemaCodecFactory` has been configured in solrconfig.xml. |n/a
|postingsFormat |Defines a custom `PostingsFormat` to use for fields of this type. This requires that a schema-aware codec, such as the `SchemaCodecFactory` has been configured in solrconfig.xml. |n/a
|===
[NOTE]
====
-
Lucene index back-compatibility is only supported for the default codec. If you choose to customize the `postingsFormat` or `docValuesFormat` in your schema.xml, upgrading to a future version of Solr may require you to either switch back to the default codec and optimize your index to rewrite it into the default codec before upgrading, or re-build your entire index from scratch after upgrading.
-
====
-[[FieldTypeDefinitionsandProperties-FieldDefaultProperties]]
=== Field Default Properties
-These are properties that can be specified either on the field types, or on individual fields to override the values provided by the field types. The default values for each property depend on the underlying `FieldType` class, which in turn may depend on the `version` attribute of the `<schema/>`. The table below includes the default value for most `FieldType` implementations provided by Solr, assuming a `schema.xml` that declares `version="1.6"`.
+These are properties that can be specified either on the field types, or on individual fields to override the values provided by the field types.
-[width="100%",cols="25%,25%,25%,25%",options="header",]
+The default values for each property depend on the underlying `FieldType` class, which in turn may depend on the `version` attribute of the `<schema/>`. The table below includes the default value for most `FieldType` implementations provided by Solr, assuming a `schema.xml` that declares `version="1.6"`.
+
+[width="100%",options="header",]
|===
|Property |Description |Values |Implicit Default
|indexed |If true, the value of the field can be used in queries to retrieve matching documents. |true or false |true
@@ -102,4 +103,6 @@ These are properties that can be specified either on the field types, or on indi
[[FieldTypeDefinitionsandProperties-FieldTypeSimilarity]]
== Field Type Similarity
-A field type may optionally specify a `<similarity/>` that will be used when scoring documents that refer to fields with this type, as long as the "global" similarity for the collection allows it. By default, any field type which does not define a similarity, uses `BM25Similarity`. For more details, and examples of configuring both global & per-type Similarities, please see <<other-schema-elements.adoc#OtherSchemaElements-Similarity,Other Schema Elements>>.
+A field type may optionally specify a `<similarity/>` that will be used when scoring documents that refer to fields with this type, as long as the "global" similarity for the collection allows it.
+
+By default, any field type which does not define a similarity, uses `BM25Similarity`. For more details, and examples of configuring both global & per-type Similarities, please see <<other-schema-elements.adoc#OtherSchemaElements-Similarity,Other Schema Elements>>.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/ccf5dd28/solr/solr-ref-guide/src/field-types-included-with-solr.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/field-types-included-with-solr.adoc b/solr/solr-ref-guide/src/field-types-included-with-solr.adoc
index 5ff082f..d6872fc 100644
--- a/solr/solr-ref-guide/src/field-types-included-with-solr.adoc
+++ b/solr/solr-ref-guide/src/field-types-included-with-solr.adoc
@@ -4,7 +4,7 @@
The following table lists the field types that are available in Solr. The `org.apache.solr.schema` package includes all the classes listed in this table.
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Class |Description
|BinaryField |Binary data.
@@ -34,5 +34,5 @@ The following table lists the field types that are available in Solr. The `org.a
|FloatPointField |Floating point field (32-bit IEEE floating point). This class functions similarly to TrieFloatField, but using a "Dimensional Points" based data structure instead of indexed terms, and doesn't require configuration of a precision step. For single valued fields, `docValues="true"` must be used to enable sorting.
|IntPointField |Integer field (32-bit signed integer). This class functions similarly to TrieIntField, but using a "Dimensional Points" based data structure instead of indexed terms, and doesn't require configuration of a precision step. For single valued fields, `docValues="true"` must be used to enable sorting.
|LongPointField |Long field (64-bit signed integer). This class functions similarly to TrieLongField, but using a "Dimensional Points" based data structure instead of indexed terms, and doesn't require configuration of a precision step. For single valued fields, `docValues="true"` must be used to enable sorting.
-|UUIDField |Universally Unique Identifier (UUID). Pass in a value of "NEW" and Solr will create a new UUID. **Note**: configuring a UUIDField instance with a default value of "NEW" is not advisable for most users when using SolrCloud (and not possible if the UUID value is configured as the unique key field) since the result will be that each replica of each document will get a unique UUID value. Using UUIDUpdateProcessorFactory to generate UUID values when documents are added is recommended instead.
+|UUIDField |Universally Unique Identifier (UUID). Pass in a value of "NEW" and Solr will create a new UUID. *Note*: configuring a UUIDField instance with a default value of "NEW" is not advisable for most users when using SolrCloud (and not possible if the UUID value is configured as the unique key field) since the result will be that each replica of each document will get a unique UUID value. Using UUIDUpdateProcessorFactory to generate UUID values when documents are added is recommended instead.
|===
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/ccf5dd28/solr/solr-ref-guide/src/files-screen.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/files-screen.adoc b/solr/solr-ref-guide/src/files-screen.adoc
index 799077c..b160276 100644
--- a/solr/solr-ref-guide/src/files-screen.adoc
+++ b/solr/solr-ref-guide/src/files-screen.adoc
@@ -4,12 +4,12 @@
The Files screen lets you browse & view the various configuration files (such `solrconfig.xml` and the schema file) for the collection you selected.
+.The Files Screen
image::images/files-screen/files-screen.png[image,height=400]
+If you are using <<solrcloud.adoc#solrcloud,SolrCloud>>, the files displayed are the configuration files for this collection stored in ZooKeeper. In a standalone Solr installations, all files in the `conf` directory are displayed.
-If you are using <<solrcloud.adoc#solrcloud,SolrCloud>>, the files displayed are the configuration files for this collection stored in ZooKeeper (using `upconfig`), for single node Solr installations, all files in the `./conf` directory are displayed.
-
-While `solrconfig.xml` defines the behaviour of Solr as it indexes content and responds to queries, the Schema allows you to define the types of data in your content (field types), the fields your documents will be broken into, and any dynamic fields that should be generated based on patterns of field names in the incoming documents. Any other configuration files are used depending on how they are referenced in either `solrconfig.xml` or your schema.
+While `solrconfig.xml` defines the behavior of Solr as it indexes content and responds to queries, the Schema allows you to define the types of data in your content (field types), the fields your documents will be broken into, and any dynamic fields that should be generated based on patterns of field names in the incoming documents. Any other configuration files are used depending on how they are referenced in either `solrconfig.xml` or your schema.
Configuration files cannot be edited with this screen, so a text editor of some kind must be used.