In a Solr schema, how does a dynamicField pattern decide which incoming field names it matches, and what breaks a tie?

## The problem dynamic fields solve Some document shapes are not knowable up front: user-defined attributes, per-tenant metadata, sensor names, the long tail of a product catalogue's specs. Declaring every field is impossible. A `dynamicField` lets the schema say "any field whose name ends in `_i` is an integer", so the application controls the type by choosing a field name. ```xml <dynamicField name="*_i" type="pint" indexed="true" stored="true"/> <dynamicField name="*_s" type="string" indexed="true" stored="true" docValues="true"/> <dynamicField name="*_ss" type="string" indexed="true" stored="true" multiValued="true"/> <dynamicField name="*_txt" type="text_general" indexed="true" stored="true"/> ``` Indexing `{"id":"1","price_i":42,"desc_txt":"blue widget"}` needs no schema change at all. ## Pattern syntax The `name` of a dynamicField is not a regular expression. It supports exactly one `*`, and only as the first or last character. `*_i` and `attr_*` are legal; `pre*post` is not. Everything else about the declaration is identical to a normal `<field>`: `type`, `indexed`, `stored`, `docValues`, `multiValued`, `required`, `default`. ## Resolution order When Solr resolves the field name in an incoming document: 1. An **explicit** `<field name="price_i">` declaration always wins, even if a dynamic pattern also matches. This is how you carve out one special case from a broad pattern. 2. Otherwise, every matching `dynamicField` is considered and the one with the **longest pattern** is chosen. For the field `color_str_s`, the pattern `*_str_s` beats `*_s`. Declaration order in the file does not matter — only pattern length. 3. If nothing matches, the document update fails with an unknown-field error, unless a catch-all pattern exists. That third case is where the ubiquitous `<dynamicField name="*" type="ignored" multiValued="true"/>` comes in: the `ignored` fieldType is declared with `indexed="false" stored="false"`, so unmatched fields are accepted and thrown away. It stops indexing from failing on unexpected input, at the cost of hiding mistakes — a misspelled `titel_txt` is silently discarded rather than rejected. ## copyField and dynamic fields `copyField` sits next to dynamic fields in the same schema and is the other half of the wiring. A copyField directive copies the **raw source value** into another field during indexing, before either field's analyzer runs, so the destination applies its own fieldType and analysis independently. It accepts wildcards: ```xml <copyField source="*_txt" dest="text"/> <copyField source="title" dest="text" maxChars="30000"/> ``` Three properties matter. First, copying happens at index time only — adding or changing a copyField has no effect on documents already in the index, so it implies a reindex. Second, if several sources copy into one destination, or a source is multi-valued, the destination must be `multiValued="true"`. Third, `maxChars` caps how much of a long value is copied, which protects a catch-all field from a single enormous document. The classic use is a catch-all `text` field that everything copies into, searched as a single default field. The modern alternative is to skip the copy and let the edismax `qf` parameter search several fields with per-field boosts — that keeps per-field scoring signals which a catch-all field destroys, at the cost of a wider query. ## Costs and limits Dynamic fields are cheap in the schema but not free in the index. Every distinct field name that actually appears creates its own term dictionary entries, and every field with `docValues` creates its own column. A multi-tenant collection where each tenant invents its own attribute names can accumulate tens of thousands of real fields, inflating segment metadata, slowing merges and bloating heap for faceting. If field names are effectively unbounded, consider a single multi-valued field holding `name=value` tokens instead, or per-tenant collections. Schemaless field guessing is a separate mechanism that adds **explicit** field declarations to the managed schema on the fly; dynamic fields never mutate the schema at all. Teams often use dynamic fields precisely so they can leave schemaless guessing switched off. ## What interviewers probe The two facts that separate a user from someone who has debugged a schema are "explicit beats dynamic" and "longest pattern wins". The third is that a catch-all `*` mapped to `ignored` turns a loud failure into a silent one.