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/03/16 17:29:07 UTC
[20/26] lucene-solr:jira/solr-10290: SOLR-10290: Add .adoc files
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/45a148a7/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
new file mode 100644
index 0000000..9c2f88c
--- /dev/null
+++ b/solr/solr-ref-guide/src/faceting.adoc
@@ -0,0 +1,724 @@
+= Faceting
+:page-shortname: faceting
+: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-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.
+
+[[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.
+
+[[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.
+
+You can set the `facet.query` parameter multiple times to indicate that multiple queries should be used as separate facet constraints.
+
+To use facet queries in a syntax other than the default syntax, prefix the facet query with the name of the query notation. For example, to use the hypothetical `myfunc` query parser, you could set the `facet.query` parameter like so:
+
+`facet.query={!myfunc}name~fred`
+
+[[Faceting-Field-ValueFacetingParameters]]
+== Field-Value Faceting Parameters
+
+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>>.)
+
+The table below summarizes Solr's field value faceting parameters.
+
+[width="100%",cols="50%,50%",options="header",]
+|===
+|Parameter |Description
+|<<Faceting-Thefacet.fieldParameter,facet.field>> |Identifies a field to be treated as a facet.
+|<<Faceting-Thefacet.prefixParameter,facet.prefix>> |Limits the terms used for faceting to those that begin with the specified prefix.
+|<<Faceting-Thefacet.containsParameter,facet.contains>> |Limits the terms used for faceting to those that contain the specified substring.
+|<<Faceting-Thefacet.contains.ignoreCaseParameter,facet.contains.ignoreCase>> |If facet.contains is used, ignore case when searching for the specified substring.
+|<<Faceting-Thefacet.sortParameter,facet.sort>> |Controls how faceted results are sorted.
+|<<Faceting-Thefacet.limitParameter,facet.limit>> |Controls how many constraints should be returned for each facet.
+|<<Faceting-Thefacet.offsetParameter,facet.offset>> |Specifies an offset into the facet results at which to begin displaying facets.
+|<<Faceting-Thefacet.mincountParameter,facet.mincount>> |Specifies the minimum counts required for a facet field to be included in the response.
+|<<Faceting-Thefacet.missingParameter,facet.missing>> |Controls whether Solr should compute a count of all matching results which have no value for the field, in addition to the term-based constraints of a facet field.
+|<<Faceting-Thefacet.methodParameter,facet.method>> |Selects the algorithm or method Solr should use when faceting a field.
+|<<Faceting-Thefacet.existsParameter,facet.exists>> |Caps facet counts by one. Available only for facet.method=enum as performance optimization.
+|<<Faceting-Thefacet.enum.cache.minDfParameter,facet.enum.cache.minDF>> |(Advanced) Specifies the minimum document frequency (the number of documents matching a term) for which the `filterCache` should be used when determining the constraint count for that term.
+|<<Faceting-Over-RequestParameters,facet.overrequest.count>> |(Advanced) A number of documents, beyond the effective `facet.limit` to request from each shard in a distributed search
+|<<Faceting-Over-RequestParameters,facet.overrequest.ratio>> |(Advanced) A multiplier of the effective `facet.limit` to request from each shard in a distributed search
+|<<Faceting-Thefacet.threadsParameter,facet.threads>> |(Advanced) Controls parallel execution of field faceting
+|===
+
+These parameters are described in the sections below.
+
+[[Faceting-Thefacet.fieldParameter]]
+=== The `facet.field` Parameter
+
+The `facet.field` parameter identifies a field that should be treated as a facet. It iterates over each Term in the field and generate a facet count using that Term as the constraint. This parameter can be specified multiple times in a query to select multiple facet fields.
+
+[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]]
+=== The `facet.prefix` Parameter
+
+The `facet.prefix` parameter limits the terms on which to facet to those starting with the given string prefix. This does not limit the query in any way, only the facets that would be returned in response to the query.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.prefix`.
+
+[[Faceting-Thefacet.containsParameter]]
+=== The `facet.contains` Parameter
+
+The `facet.contains` parameter limits the terms on which to facet to those containing the given substring. This does not limit the query in any way, only the facets that would be returned in response to the query.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.contains`.
+
+[[Faceting-Thefacet.contains.ignoreCaseParameter]]
+=== The `facet.contains.ignoreCase` Parameter
+
+If `facet.contains` is used, the `facet.contains.ignoreCase` parameter causes case to be ignored when matching the given substring against candidate facet terms.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.contains.ignoreCase`.
+
+[[Faceting-Thefacet.sortParameter]]
+=== The `facet.sort` Parameter
+
+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.
+|===
+
+The default is `count` if `facet.limit` is greater than 0, otherwise, the default is `index`.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.sort`.
+
+[[Faceting-Thefacet.limitParameter]]
+=== The `facet.limit` Parameter
+
+This parameter specifies the maximum number of constraint counts (essentially, the number of facets for a field that are returned) that should be returned for the facet fields. A negative value means that Solr will return unlimited number of constraint counts.
+
+The default value is 100.
+
+This parameter can be specified on a per-field basis to apply a distinct limit to each field with the syntax of `f.<fieldname>.facet.limit`.
+
+[[Faceting-Thefacet.offsetParameter]]
+=== The `facet.offset` Parameter
+
+The `facet.offset` parameter indicates an offset into the list of constraints to allow paging.
+
+The default value is 0.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.offset`.
+
+[[Faceting-Thefacet.mincountParameter]]
+=== The `facet.mincount` Parameter
+
+The `facet.mincount` parameter specifies the minimum counts required for a facet field to be included in the response. If a field's counts are below the minimum, the field's facet is not returned.
+
+The default value is 0.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.mincount`.
+
+[[Faceting-Thefacet.missingParameter]]
+=== The `facet.missing` Parameter
+
+If set to true, this parameter indicates that, in addition to the Term-based constraints of a facet field, a count of all results that match the query but which have no facet value for the field should be computed and returned in the response.
+
+The default value is false.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.missing`.
+
+[[Faceting-Thefacet.methodParameter]]
+=== The `facet.method` Parameter
+
+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 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.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.method`.
+
+[[Faceting-Thefacet.enum.cache.minDfParameter]]
+=== The `facet.enum.cache.minDf` Parameter
+
+This parameter indicates the minimum document frequency (the number of documents matching a term) for which the filterCache should be used when determining the constraint count for that term. This is only used with the `facet.method=enum` method of faceting.
+
+A value greater than zero decreases the filterCache's memory usage, but increases the time required for the query to be processed. If you are faceting on a field with a very large number of terms, and you wish to decrease memory usage, try setting this parameter to a value between 25 and 50, and run a few tests. Then, optimize the parameter setting as necessary.
+
+The default value is 0, causing the filterCache to be used for all terms in the field.
+
+This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.enum.cache.minDF`.
+
+[[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..
+
+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`
+
+[[Faceting-Over-RequestParameters]]
+=== Over-Request Parameters
+
+In some situations, the accuracy in selecting the "top" constraints returned for a facet in a distributed Solr query can be improved by "Over Requesting" the number of desired constraints (ie: `facet.limit`) from each of the individual Shards. In these situations, each shard is by default asked for the top "`10 + (1.5 * facet.limit)`" constraints.
+
+In some situations, depending on how your docs are partitioned across your shards, and what `facet.limit` value you used, you may find it advantageous to increase or decrease the amount of over-requesting Solr does. This can be achieved by setting the `facet.overrequest.count` (defaults to 10) and `facet.overrequest.ratio` (defaults to 1.5) parameters.
+
+[[Faceting-Thefacet.threadsParameter]]
+=== The `facet.threads` Parameter
+
+This param will cause loading the underlying fields used in faceting to be executed in parallel with the number of threads specified. Specify as `facet.threads=N` where `N` is the maximum number of threads used. Omitting this parameter or specifying the thread count as 0 will not spawn any threads, and only the main request thread will be used. Specifying a negative number of threads will create up to Integer.MAX_VALUE threads.
+
+[[Faceting-RangeFaceting]]
+== Range Faceting
+
+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",]
+|===
+|Parameter |Description
+|<<Faceting-Thefacet.rangeParameter,facet.range>> |Specifies the field to facet by range.
+|<<Faceting-Thefacet.range.startParameter,facet.range.start>> |Specifies the start of the facet range.
+|<<Faceting-Thefacet.range.endParameter,facet.range.end>> |Specifies the end of the facet range.
+|<<Faceting-Thefacet.range.gapParameter,facet.range.gap>> |Specifies the span of the range as a value to be added to the lower bound.
+|<<Faceting-Thefacet.range.hardendParameter,facet.range.hardend>> |A boolean parameter that specifies how Solr handles a range gap that cannot be evenly divided between the range start and end values. If true, the last range constraint will have the `facet.range.end` value 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.
+|<<Faceting-Thefacet.range.includeParameter,facet.range.include>> |Specifies inclusion and exclusion preferences for the upper and lower bounds of the range. See the `facet.range.include` topic for more detailed information.
+|<<Faceting-Thefacet.range.otherParameter,facet.range.other>> |Specifies counts for Solr to compute in addition to the counts for each facet range constraint.
+|<<Faceting-Thefacet.range.methodParameter,facet.range.method>> |Specifies the algorithm or method to use for calculating facets.
+|===
+
+[[Faceting-Thefacet.rangeParameter]]
+=== The `facet.range` Parameter
+
+The `facet.range` parameter defines the field for which Solr should create range facets. For example:
+
+`facet.range=price&facet.range=age`
+
+`facet.range=lastModified_dt`
+
+[[Faceting-Thefacet.range.startParameter]]
+=== The `facet.range.start` Parameter
+
+The `facet.range.start` parameter specifies the lower bound of the ranges. You can specify this parameter on a per field basis with the syntax of `f.<fieldname>.facet.range.start`. For example:
+
+`f.price.facet.range.start=0.0&f.age.facet.range.start=10`
+
+`f.lastModified_dt.facet.range.start=NOW/DAY-30DAYS`
+
+[[Faceting-Thefacet.range.endParameter]]
+=== The `facet.range.end` Parameter
+
+The facet.range.end specifies the upper bound of the ranges. You can specify this parameter on a per field basis with the syntax of `f.<fieldname>.facet.range.end`. For example:
+
+`f.price.facet.range.end=1000.0&f.age.facet.range.start=99`
+
+`f.lastModified_dt.facet.range.end=NOW/DAY+30DAYS`
+
+[[Faceting-Thefacet.range.gapParameter]]
+=== The `facet.range.gap` Parameter
+
+The span of each range expressed as a value to be added to the lower bound. For date fields, this should be expressed using the {solr-javadocs}/solr-core/org/apache/solr/util/DateMathParser.html[`DateMathParser` syntax] (such as, `facet.range.gap=%2B1DAY ... '+1DAY'`). You can specify this parameter on a per-field basis with the syntax of `f.<fieldname>.facet.range.gap`. For example:
+
+`f.price.facet.range.gap=100&f.age.facet.range.gap=10`
+
+`f.lastModified_dt.facet.range.gap=+1DAY`
+
+[[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.
+
+This parameter can be specified on a per field basis with the syntax `f.<fieldname>.facet.range.hardend`.
+
+[[Faceting-Thefacet.range.includeParameter]]
+=== The `facet.range.include` Parameter
+
+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",]
+|===
+|Option |Description
+|lower |All gap-based ranges include their lower bound.
+|upper |All gap-based ranges include their upper bound.
+|edge |The first and last gap ranges include their edge bounds (lower for the first one, upper for the last one) even if the corresponding upper/lower option is not specified.
+|outer |The "before" and "after" ranges will be inclusive of their bounds, even if the first or last ranges already include those boundaries.
+|all |Includes all options: lower, upper, edge, outer.
+|===
+
+You can specify this parameter on a per field basis with the syntax of `f.<fieldname>.facet.range.include`, and you can specify it multiple times to indicate multiple choices.
+
+[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]]
+=== The `facet.range.other` Parameter
+
+The `facet.range.other` parameter specifies that in addition to the counts for each range constraint between `facet.range.start` and `facet.range.end`, counts should also be computed for these options:
+
+[width="100%",cols="50%,50%",options="header",]
+|===
+|Option |Description
+|before |All records with field values lower then lower bound of the first range.
+|after |All records with field values greater then the upper bound of the last range.
+|between |All records with field values between the start and end bounds of all ranges.
+|none |Do not compute any counts.
+|all |Compute counts for before, between, and after.
+|===
+
+This parameter can be specified on a per field basis with the syntax of `f.<fieldname>.facet.range.other`. In addition to the `all` option, this parameter can be specified multiple times to indicate multiple choices, but `none` will override all other options.
+
+[[Faceting-Thefacet.range.methodParameter]]
+=== The `facet.range.method` Parameter
+
+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>>.
+|===
+
+Default value for this parameter is "filter".
+
+[[Faceting-Thefacet.mincountParameterinRangeFaceting]]
+=== 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.
+
+.Date Ranges & Time Zones
+[NOTE]
+====
+
+Range faceting on date fields is a common situation where the <<working-with-dates.adoc#WorkingwithDates-TZ,`TZ`>> parameter can be useful to ensure that the "facet counts per day" or "facet counts per month" are based on a meaningful definition of when a given day/month "starts" relative to a particular TimeZone.
+
+For more information, see the examples in the <<working-with-dates.adoc#working-with-dates,Working with Dates>> section.
+
+====
+
+// OLD_CONFLUENCE_ID: Faceting-Pivot(DecisionTree)Faceting
+
+[[Faceting-Pivot_DecisionTree_Faceting]]
+== Pivot (Decision Tree) Faceting
+
+Pivoting is a summarization tool that lets you automatically sort, count, total or average data stored in a table. The results are typically displayed in a second table showing the summarized data. Pivot faceting lets you create a summary table of the results from a faceting documents by multiple fields.
+
+Another way to look at it is that the query produces a Decision Tree, in that Solr tells you "for facet A, the constraints/counts are X/N, Y/M, etc. If you were to constrain A by X, then the constraint counts for B would be S/P, T/Q, etc.". In other words, it tells you in advance what the "next" set of facet results would be for a field if you apply a constraint from the current facet results.
+
+[[Faceting-facet.pivot]]
+=== facet.pivot
+
+The `facet.pivot` parameter defines the fields to use for the pivot. Multiple `facet.pivot` values will create multiple "facet_pivot" sections in the response. Separate each list of fields with a comma.
+
+[[Faceting-facet.pivot.mincount]]
+=== facet.pivot.mincount
+
+The `facet.pivot.mincount` parameter defines the minimum number of documents that need to match in order for the facet to be included in results. The default is 1.
+
+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]
+----
+http://localhost:8983/solr/techproducts/select?q=*:*&facet.pivot=cat,popularity,inStock
+ &facet.pivot=popularity,cat&facet=true&facet.field=cat&facet.limit=5
+ &rows=0&wt=json&indent=true&facet.pivot.mincount=2
+----
+
+[source,json]
+----
+ "facet_counts":{
+ "facet_queries":{},
+ "facet_fields":{
+ "cat":[
+ "electronics",14,
+ "currency",4,
+ "memory",3,
+ "connector",2,
+ "graphics card",2]},
+ "facet_dates":{},
+ "facet_ranges":{},
+ "facet_pivot":{
+ "cat,popularity,inStock":[{
+ "field":"cat",
+ "value":"electronics",
+ "count":14,
+ "pivot":[{
+ "field":"popularity",
+ "value":6,
+ "count":5,
+ "pivot":[{
+ "field":"inStock",
+ "value":true,
+ "count":5}]},
+...
+----
+
+[[Faceting-CombiningStatsComponentWithPivots]]
+=== Combining Stats Component With Pivots
+
+In addition to some of the <<Faceting-LocalParametersforFaceting,general local parameters>> supported by other types of faceting, a `stats` local parameters can be used with `facet.pivot` to refer to <<the-stats-component.adoc#the-stats-component,`stats.field`>> instances (by tag) that you would like to have computed for each Pivot Constraint.
+
+In the example below, two different (overlapping) sets of statistics are computed for each of the facet.pivot result hierarchies:
+
+[source,java]
+----
+stats=true
+stats.field={!tag=piv1,piv2 min=true max=true}price
+stats.field={!tag=piv2 mean=true}popularity
+facet=true
+facet.pivot={!stats=piv1}cat,inStock
+facet.pivot={!stats=piv2}manu,inStock
+----
+
+Results:
+
+[source,java]
+----
+"facet_pivot":{
+ "cat,inStock":[{
+ "field":"cat",
+ "value":"electronics",
+ "count":12,
+ "pivot":[{
+ "field":"inStock",
+ "value":true,
+ "count":8,
+ "stats":{
+ "stats_fields":{
+ "price":{
+ "min":74.98999786376953,
+ "max":399.0}}}},
+ {
+ "field":"inStock",
+ "value":false,
+ "count":4,
+ "stats":{
+ "stats_fields":{
+ "price":{
+ "min":11.5,
+ "max":649.989990234375}}}}],
+ "stats":{
+ "stats_fields":{
+ "price":{
+ "min":11.5,
+ "max":649.989990234375}}}},
+ {
+ "field":"cat",
+ "value":"currency",
+ "count":4,
+ "pivot":[{
+ "field":"inStock",
+ "value":true,
+ "count":4,
+ "stats":{
+ "stats_fields":{
+ "price":{
+ ...
+ "manu,inStock":[{
+ "field":"manu",
+ "value":"inc",
+ "count":8,
+ "pivot":[{
+ "field":"inStock",
+ "value":true,
+ "count":7,
+ "stats":{
+ "stats_fields":{
+ "price":{
+ "min":74.98999786376953,
+ "max":2199.0},
+ "popularity":{
+ "mean":5.857142857142857}}}},
+ {
+ "field":"inStock",
+ "value":false,
+ "count":1,
+ "stats":{
+ "stats_fields":{
+ "price":{
+ "min":479.95001220703125,
+ "max":479.95001220703125},
+ "popularity":{
+ "mean":7.0}}}}],
+ ...
+----
+
+[[Faceting-CombiningFacetQueriesAndFacetRangesWithPivotFacets]]
+=== Combining Facet Queries And Facet Ranges With Pivot Facets
+
+A `query` local parameter can be used with `facet.pivot` to refer to `facet.query` instances (by tag) that should be computed for each pivot constraint. Similarly, a `range` local parameter can be used with `facet.pivot` to refer to `facet.range` instances.
+
+In the example below, two query facets are computed for h of the `facet.pivot` result hierarchies:
+
+[source,java]
+----
+facet=true
+facet.query={!tag=q1}manufacturedate_dt:[2006-01-01T00:00:00Z TO NOW]
+facet.query={!tag=q1}price:[0 TO 100]
+facet.pivot={!query=q1}cat,inStock
+----
+
+[source,java]
+----
+ "facet_counts": {
+ "facet_queries": {
+ "{!tag=q1}manufacturedate_dt:[2006-01-01T00:00:00Z TO NOW]": 9,
+ "{!tag=q1}price:[0 TO 100]": 7
+ },
+ "facet_fields": {},
+ "facet_dates": {},
+ "facet_ranges": {},
+ "facet_intervals": {},
+ "facet_heatmaps": {},
+ "facet_pivot": {
+ "cat,inStock": [
+ {
+ "field": "cat",
+ "value": "electronics",
+ "count": 12,
+ "queries": {
+ "{!tag=q1}manufacturedate_dt:[2006-01-01T00:00:00Z TO NOW]": 9,
+ "{!tag=q1}price:[0 TO 100]": 4
+ },
+ "pivot": [
+ {
+ "field": "inStock",
+ "value": true,
+ "count": 8,
+ "queries": {
+ "{!tag=q1}manufacturedate_dt:[2006-01-01T00:00:00Z TO NOW]": 6,
+ "{!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]
+----
+facet=true
+facet.range={!tag=r1}manufacturedate_dt
+facet.range.start=2006-01-01T00:00:00Z
+facet.range.end=NOW/YEAR
+facet.range.gap=+1YEAR
+facet.pivot={!range=r1}cat,inStock
+----
+
+[source,java]
+----
+ "facet_counts":{
+ "facet_queries":{},
+ "facet_fields":{},
+ "facet_dates":{},
+ "facet_ranges":{
+ "manufacturedate_dt":{
+ "counts":[
+ "2006-01-01T00:00:00Z",9,
+ "2007-01-01T00:00:00Z",0,
+ "2008-01-01T00:00:00Z",0,
+ "2009-01-01T00:00:00Z",0,
+ "2010-01-01T00:00:00Z",0,
+ "2011-01-01T00:00:00Z",0,
+ "2012-01-01T00:00:00Z",0,
+ "2013-01-01T00:00:00Z",0,
+ "2014-01-01T00:00:00Z",0],
+ "gap":"+1YEAR",
+ "start":"2006-01-01T00:00:00Z",
+ "end":"2015-01-01T00:00:00Z"}},
+ "facet_intervals":{},
+ "facet_heatmaps":{},
+ "facet_pivot":{
+ "cat,inStock":[{
+ "field":"cat",
+ "value":"electronics",
+ "count":12,
+ "ranges":{
+ "manufacturedate_dt":{
+ "counts":[
+ "2006-01-01T00:00:00Z",9,
+ "2007-01-01T00:00:00Z",0,
+ "2008-01-01T00:00:00Z",0,
+ "2009-01-01T00:00:00Z",0,
+ "2010-01-01T00:00:00Z",0,
+ "2011-01-01T00:00:00Z",0,
+ "2012-01-01T00:00:00Z",0,
+ "2013-01-01T00:00:00Z",0,
+ "2014-01-01T00:00:00Z",0],
+ "gap":"+1YEAR",
+ "start":"2006-01-01T00:00:00Z",
+ "end":"2015-01-01T00:00:00Z"}},
+ "pivot":[{
+ "field":"inStock",
+ "value":true,
+ "count":8,
+ "ranges":{
+ "manufacturedate_dt":{
+ "counts":[
+ "2006-01-01T00:00:00Z",6,
+ "2007-01-01T00:00:00Z",0,
+ "2008-01-01T00:00:00Z",0,
+ "2009-01-01T00:00:00Z",0,
+ "2010-01-01T00:00:00Z",0,
+ "2011-01-01T00:00:00Z",0,
+ "2012-01-01T00:00:00Z",0,
+ "2013-01-01T00:00:00Z",0,
+ "2014-01-01T00:00:00Z",0],
+ "gap":"+1YEAR",
+ "start":"2006-01-01T00:00:00Z",
+ "end":"2015-01-01T00:00:00Z"}}},
+ ...
+----
+
+[[Faceting-AdditionalPivotParameters]]
+=== Additional Pivot Parameters
+
+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.sort` <<Faceting-Thefacet.sortParameter,The facet.sort Parameter>>
+* ` 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.
+
+[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.
+|===
+
+[[Faceting-Thefacet.intervalparameter]]
+=== The `facet.interval` parameter
+
+This parameter Indicates the field where interval faceting must be applied. It can be used multiple times in the same request to indicate multiple fields.
+
+`facet.interval=price&facet.interval=size`
+
+[[Faceting-Thefacet.interval.setparameter]]
+=== The `facet.interval.set` parameter
+
+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:
+
+....
+f.price.facet.interval.set=[0,10]&f.price.facet.interval.set=(10,100]
+....
+
+[[Faceting-IntervalSyntax]]
+=== Interval Syntax
+
+Intervals must begin with either '(' or '[', be followed by the start value, then a comma (','), the end value, and finally a closing ')' or ']\u2019.
+
+For example:
+
+* (1,10) -> will include values greater than 1 and lower than 10
+* [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.
+
+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].
+
+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]
+----
+&facet.interval={!key=popularity}some_field
+&facet.interval.set={!key=bad}[0,5]
+&facet.interval.set={!key=good}[5,*]
+&facet=true
+----
+
+[[Faceting-LocalParametersforFaceting]]
+== Local Parameters for Faceting
+
+The <<local-parameters-in-queries.adoc#local-parameters-in-queries,LocalParams syntax>> allows overriding global settings. It can also provide a method of adding metadata to other parameter values, much like XML attributes.
+
+[[Faceting-TaggingandExcludingFilters]]
+=== Tagging and Excluding Filters
+
+You can tag specific filters and exclude those filters when faceting. This is useful when doing multi-select faceting.
+
+Consider the following example query with faceting:
+
+`q=mainquery&fq=status:public&fq=doctype:pdf&facet=true&facet.field=doctype`
+
+Because everything is already constrained by the filter `doctype:pdf`, the `facet.field=doctype` facet command is currently redundant and will return 0 counts for everything except `doctype:pdf`.
+
+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]
+----
+=== Document Type ===
+ [ ] Word (42)
+ [x] PDF (96)
+ [ ] Excel(11)
+ [ ] HTML (63)
+----
+
+To return counts for doctype values that are currently not selected, tag filters that directly constrain doctype, and exclude those filters when faceting on doctype.
+
+`q=mainquery&fq=status:public&fq={!tag=dt}doctype:pdf&facet=true&facet.field={!ex=dt}doctype`
+
+Filter exclusion is supported for all types of facets. Both the `tag` and `ex` local parameters may specify multiple values by separating them with commas.
+
+[[Faceting-ChangingtheOutputKey]]
+=== Changing the Output Key
+
+To change the output key for a faceting command, specify a new name with the `key` local parameter. For example:
+
+`facet.field={!ex=dt key=mylabel}doctype`
+
+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
+
+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 \,. 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 `
+
+[[Faceting-RelatedTopics]]
+== Related Topics
+
+* <<spatial-search.adoc#spatial-search,Heatmap Faceting (Spatial)>>
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/45a148a7/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
new file mode 100644
index 0000000..0c1f23a
--- /dev/null
+++ b/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
@@ -0,0 +1,25 @@
+= Field Properties by Use Case
+:page-shortname: field-properties-by-use-case
+:page-permalink: field-properties-by-use-case.html
+
+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",]
+|===
+|Use Case |indexed |stored |multiValued |omitNorms |termVectors |termPositions |docValues
+|search within field |true | | | | | |
+|retrieve contents | |true | | | | |
+|use as unique key |true | |false | | | |
+|sort on field |true^7^ | |false |true ^1^ | | |true^7^
+|use field boosts ^5^ | | | |false | | |
+|document boosts affect searches within field | | | |false | | |
+|highlighting |true ^4^ |true | | |true^2^ |true ^3^ |
+|faceting ^5^ |true^7^ | | | | | |true^7^
+|add multiple values, maintaining order | | |true | | | |
+|field length affects doc score | | | |false | | |
+|MoreLikeThis ^5^ | | | | |true ^6^ | |
+|===
+
+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^ Either `indexed` or `docValues` must be true, but both are not required. <<docvalues.adoc#docvalues,DocValues>> can be more efficient in many cases.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/45a148a7/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
new file mode 100644
index 0000000..5e689ec
--- /dev/null
+++ b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
@@ -0,0 +1,103 @@
+= Field Type Definitions and Properties
+:page-shortname: field-type-definitions-and-properties
+:page-permalink: field-type-definitions-and-properties.html
+
+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
+* Field type properties - depending on the implementation class, some properties may be mandatory.
+
+[[FieldTypeDefinitionsandProperties-FieldTypeDefinitionsinschema.xml]]
+== Field Type Definitions in `schema.xml`
+
+Field types are defined in `schema.xml`. Each field type is defined between `fieldType` elements. They can optionally be grouped within a `types` element. Here is an example of a field type definition for a type called `text_general`:
+
+[source,xml]
+----
+<fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
+ <analyzer type="index">
+ <tokenizer class="solr.StandardTokenizerFactory"/>
+ <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
+ <!-- in this example, we will only use synonyms at query time
+ <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/>
+ -->
+ <filter class="solr.LowerCaseFilterFactory"/>
+ </analyzer>
+ <analyzer type="query">
+ <tokenizer class="solr.StandardTokenizerFactory"/>
+ <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
+ <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
+ <filter class="solr.LowerCaseFilterFactory"/>
+ </analyzer>
+</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>>.
+
+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.`.
+
+[[FieldTypeDefinitionsandProperties-FieldTypeProperties]]
+== Field Type Properties
+
+The field type `class` determines most of the behavior of a field type, but optional properties can also be defined. For example, the following definition of a date field type defines two properties, `sortMissingLast` and `omitNorms`.
+
+[source,xml]
+----
+<fieldType name="date" class="solr.TrieDateField"
+ sortMissingLast="true" omitNorms="true"/>
+----
+
+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.
+
+[[FieldTypeDefinitionsandProperties-GeneralProperties]]
+=== General Properties
+
+[width="100%",cols="34%,33%,33%",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". |
+|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
+|[[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"`.
+
+[width="100%",cols="25%,25%,25%,25%",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
+|stored |If true, the actual value of the field can be retrieved by queries. |true or false |true
+|docValues |If true, the value of the field will be put in a column-oriented <<docvalues.adoc#docvalues,DocValues>> structure. |true or false |false
+|sortMissingFirst sortMissingLast |Control the placement of documents when a sort field is not present. |true or false |false
+|multiValued |If true, indicates that a single document might contain multiple values for this field type. |true or false |false
+|omitNorms |If true, omits the norms associated with this field (this disables length normalization and index-time boosting for the field, and saves some memory). *Defaults to true for all primitive (non-analyzed) field types, such as int, float, data, bool, and string.* Only full-text fields or fields that need an index-time boost need norms. |true or false |*
+|omitTermFreqAndPositions |If true, omits term frequency, positions, and payloads from postings for this field. This can be a performance boost for fields that don't require that information. It also reduces the storage space required for the index. Queries that rely on position that are issued on a field with this option will silently fail to find documents. *This property defaults to true for all field types that are not text fields.* |true or false |*
+|omitPositions |Similar to `omitTermFreqAndPositions` but preserves term frequency information. |true or false |*
+|termVectors termPositions termOffsets termPayloads |These options instruct Solr to maintain full term vectors for each document, optionally including position, offset and payload information for each term occurrence in those vectors. These can be used to accelerate highlighting and other ancillary functionality, but impose a substantial cost in terms of index size. They are not necessary for typical uses of Solr. |true or false |false
+|required |Instructs Solr to reject any attempts to add a document which does not have a value for this field. This property defaults to false. |true or false |false
+|useDocValuesAsStored |If the field has <<docvalues.adoc#docvalues,docValues>> enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <<common-query-parameters.adoc#CommonQueryParameters-Thefl_FieldList_Parameter,fl parameter>>. |true or false |true
+|===
+
+[[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>>.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/45a148a7/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
new file mode 100644
index 0000000..be05b50
--- /dev/null
+++ b/solr/solr-ref-guide/src/field-types-included-with-solr.adoc
@@ -0,0 +1,32 @@
+= Field Types Included with Solr
+:page-shortname: field-types-included-with-solr
+:page-permalink: field-types-included-with-solr.html
+
+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",]
+|===
+|Class |Description
+|BinaryField |Binary data.
+|BoolField |Contains either true or false. Values of "1", "t", or "T" in the first character are interpreted as true. Any other values in the first character are interpreted as false.
+|CollationField |Supports Unicode collation for sorting and range queries. ICUCollationField is a better choice if you can use ICU4J. See the section <<language-analysis.adoc#LanguageAnalysis-UnicodeCollation,Unicode Collation>>.
+|CurrencyField |Supports currencies and exchange rates. See the section <<working-with-currencies-and-exchange-rates.adoc#working-with-currencies-and-exchange-rates,Working with Currencies and Exchange Rates>>.
+|DateRangeField |Supports indexing date ranges, to include point in time date instances as well (single-millisecond durations). See the section <<working-with-dates.adoc#working-with-dates,Working with Dates>> for more detail on using this field type. Consider using this field type even if it's just for date instances, particularly when the queries typically fall on UTC year/month/day/hour, etc., boundaries.
+|ExternalFileField |Pulls values from a file on disk. See the section <<working-with-external-files-and-processes.adoc#working-with-external-files-and-processes,Working with External Files and Processes>>.
+|EnumField |Allows defining an enumerated set of values which may not be easily sorted by either alphabetic or numeric order (such as a list of severities, for example). This field type takes a configuration file, which lists the proper order of the field values. See the section <<working-with-enum-fields.adoc#working-with-enum-fields,Working with Enum Fields>> for more information.
+|ICUCollationField |Supports Unicode collation for sorting and range queries. See the section <<language-analysis.adoc#LanguageAnalysis-UnicodeCollation,Unicode Collation>>.
+|LatLonType |<<spatial-search.adoc#spatial-search,Spatial Search>>: a latitude/longitude coordinate pair. The latitude is specified first in the pair.
+|PointType |<<spatial-search.adoc#spatial-search,Spatial Search>>: An arbitrary n-dimensional point, useful for searching sources such as blueprints or CAD drawings.
+|PreAnalyzedField |Provides a way to send to Solr serialized token streams, optionally with independent stored values of a field, and have this information stored and indexed without any additional text processing. Configuration and usage of PreAnalyzedField is documented on the <<working-with-external-files-and-processes.adoc#WorkingwithExternalFilesandProcesses-ThePreAnalyzedFieldType,Working with External Files and Processes>> page.
+|RandomSortField |Does not contain a value. Queries that sort on this field type will return results in random order. Use a dynamic field to use this feature.
+|SpatialRecursivePrefixTreeFieldType |(RPT for short) <<spatial-search.adoc#spatial-search,Spatial Search>>: Accepts latitude comma longitude strings or other shapes in WKT format.
+|StrField |String (UTF-8 encoded string or Unicode). Strings are intended for small fields and are _not_ tokenized or analyzed in any way. They have a hard limit of slightly less than 32K.
+|TextField |Text, usually multiple words or tokens.
+|TrieDateField |Date field. Represents a point in time with millisecond precision. See the section <<working-with-dates.adoc#working-with-dates,Working with Dates>>. `precisionStep="0"` enables efficient date sorting and minimizes index size; `precisionStep="8"` (the default) enables efficient range queries.
+|TrieDoubleField |Double field (64-bit IEEE floating point). `precisionStep="0"` enables efficient numeric sorting and minimizes index size; `precisionStep="8"` (the default) enables efficient range queries.
+|TrieField |If this field type is used, a "type" attribute must also be specified, valid values are: `integer`, `long`, `float`, `double`, `date`. Using this field is the same as using any of the Trie fields. `precisionStep="0"` enables efficient numeric sorting and minimizes index size; `precisionStep="8"` (the default) enables efficient range queries.
+|TrieFloatField |Floating point field (32-bit IEEE floating point) . `precisionStep="0"` enables efficient numeric sorting and minimizes index size; `precisionStep="8"` (the default) enables efficient range queries.
+|TrieIntField |Integer field (32-bit signed integer). `precisionStep="0"` enables efficient numeric sorting and minimizes index size; `precisionStep="8"` (the default) enables efficient range queries.
+|TrieLongField |Long field (64-bit signed integer). `precisionStep="0"` enables efficient numeric sorting and minimizes index size; `precisionStep="8"` (the default) enables efficient range queries.
+|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/45a148a7/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
new file mode 100644
index 0000000..799077c
--- /dev/null
+++ b/solr/solr-ref-guide/src/files-screen.adoc
@@ -0,0 +1,23 @@
+= Files Screen
+:page-shortname: files-screen
+:page-permalink: files-screen.html
+
+The Files screen lets you browse & view the various configuration files (such `solrconfig.xml` and the schema file) for the collection you selected.
+
+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 (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.
+
+Configuration files cannot be edited with this screen, so a text editor of some kind must be used.
+
+This screen is related to the <<schema-browser-screen.adoc#schema-browser-screen,Schema Browser Screen>>, in that they both can display information from the schema, but the Schema Browser provides a way to drill into the analysis chain and displays linkages between field types, fields, and dynamic field rules.
+
+Many of the options defined in these configuration files are described throughout the rest of this Guide. In particular, you will want to review these sections:
+
+* <<indexing-and-basic-data-operations.adoc#indexing-and-basic-data-operations,Indexing and Basic Data Operations>>
+* <<searching.adoc#searching,Searching>>
+* <<the-well-configured-solr-instance.adoc#the-well-configured-solr-instance,The Well-Configured Solr Instance>>
+* https://cwiki.apache.org/confluence/display/solr/Documents%2C+Fields%2C+and+Schema+Design[Documents, Fields, and Schema Design]