Field types

StrField stores a value as a single, unanalyzed, verbatim string — the Solr equivalent of Elasticsearch’s keyword. Use it for ids, tags, hostnames, and anything filtered on exactly or sorted on; it takes no <analyzer>.

TextField runs the value through an index analyzer (and, if different, a query analyzer) that tokenizes, lowercases, and often stems it into terms — the type behind full-text search. See Text analysis for the tokenizer/filter chain itself and Language analysis for language-specific stemming.

Change the schema over HTTP instead of hand-editing managed-schema with the Schema API’s add-field-type command:

Solr’s numeric and date field types are point-based: IntPointField, LongPointField, FloatPointField, DoublePointField, and DatePointField, all built on Lucene’s dimensional-point index structure. This is the only supported family of numeric field types — the older Trie* classes (TrieIntField, TrieLongField, TrieFloatField, TrieDoubleField, TrieDateField) have been removed from current Solr; a managed-schema that still declares one will fail to load. Any example, tutorial, or migration guide referring to a Trie* class is describing a pre-removal Solr version and needs the equivalent *PointField substituted.

Point fields are optimized for range queries and are compact on disk, but — unlike the old Trie fields — they carry no docValues by default and cannot be sorted, faceted, or used in function queries without them. Always set docValues="true" on a point field type (or on the individual field) if you will ever sort, facet, or stats on it; see Indexing internals & performance for what docValues costs and buys at index time. See Field Types Included with Solr for the full class list and Field Type Definitions and Properties for every property below.

DatePointField stores an instant with millisecond precision, always in UTC, formatted as ISO-8601 (1969-06-01T00:00:00Z, or a bare 1969-06-01 — Solr fills in midnight UTC). Queries and values accept date math: a base of a literal timestamp or NOW, followed by +/- offsets (+1DAY, -6MONTHS) and / rounding to a unit (/DAY, /YEAR).

NOW resolves once per request and is cached per millisecond by default, which keeps fq clauses built from it reusable across the filter cache within the same request; pin it explicitly (NOW=<epoch_ms>) if a multi-request workflow needs the identical instant throughout. DateRangeField is a related, separate type for indexing date ranges (not just instants) with correct overlap semantics — see Field Types Included with Solr.

Stores true/false (also accepted on input as T/F and 1/0). Sorts false before true.

Encodes a fixed, ordered set of string values as their position in that order rather than lexicographically — so sorting EnumFieldType follows the enum’s declared order (LOW, MEDIUM, HIGH) instead of alphabetical order, and it takes less space than an equivalent string. The value set lives in a separate enumsConfig.xml, referenced from the field type by enumsConfig and enumName.

CurrencyFieldType stores an amount together with a currency code ("19.99,USD"), and can convert between currencies at query time via a pluggable, configurable exchange-rate provider (a static rate file or an external rate service) so a range query in one currency correctly matches values stored in another.

Stores a 128-bit UUID as a string. A field of this type left empty on input can be told to self-generate a value with <update><processor class="solr.UUIDUpdateProcessorFactory">, a common choice for a uniqueKey that clients should not have to invent.

LatLonPointSpatialField is the current, recommended type for a plain latitude/longitude point — Lucene-backed, indexed with dimensional points like the numeric *PointField types above, and fast for both distance-sort and bounding-box/radius filters. Older spatial types (PointType, SpatialRecursivePrefixTreeFieldType, BBoxField) remain available for shapes or legacy schemas but are not the default choice for a point. See Spatial search for query syntax and Field Types Included with Solr for the full spatial type list.

Outside a [source] block, that same local-params filter is written escaped, as \{!geofilt sfield=store_location pt=40.7,-74.0 d=10}, so AsciiDoc does not try to interpret the braces.

Stores a fixed-length float (or byte) vector for k-nearest-neighbor search over embeddings — Solr’s counterpart to Elasticsearch’s dense_vector. The type declares the vector dimension and similarity function; a field of this type is queried with the knn query parser rather than a term or range query. See Dense vector search for indexing and query examples, and Query parsers for knn alongside Solr’s other parsers.

Two layers of properties apply to a fieldType: a handful of type-level settings that only make sense on the fieldType element itself, and a larger set of field-default properties that a fieldType merely supplies a default for — any of them can be overridden per <field>. Full reference: Field Type Definitions and Properties.

Only text-family types (TextField and its SortableTextField variant) take an <analyzer>; StrField, the *PointField types, BoolField, EnumFieldType, CurrencyFieldType, UUIDField, and the spatial/vector types do not analyze their input at all — what is stored is, structurally, what was sent. Declare one <analyzer> for both index and query time, or split them with type="index" / type="query" when the two need to differ (a common case: index-time synonym expansion that must not also run at query time). Each <analyzer> chains exactly one <tokenizer> with zero or more <filter> stages. See Text analysis for the tokenizer/filter catalog and worked chains, and Language analysis for per-language stemmers and stop-word lists.

A SolrJ client never needs to know the analyzer chain — it just sends and reads field values like any other client:

Continue with Schema & fields for how these types are assigned to fields (explicit fields, dynamic-field patterns, copyField, and uniqueKey), or Text analysis for a deeper look at the tokenizer/filter chain introduced above.