Partial updates & concurrency

An atomic update sends only the fields that changed, wrapped in a modifier, instead of the whole document. Solr reads the stored document, applies the modifiers, and re-indexes the result — the untouched fields must therefore be stored or hold docValues (a copyField destination is the one exception: it must be neither, since it is always recomputed from its source).

Every indexed document carries a version field that Solr bumps on every write. Read it back with your document, then send it on the write: the shard applies the write only if the stored version still matches, otherwise it rejects the request with HTTP 409 — the same read-modify-retry contract as Elasticsearch’s if_seq_no/if_primary_term and Couchbase’s CAS token, applied to a version number instead.

The client owns the retry loop: re-read the document (and its fresh version), re-apply the change, and re-send — bounded by a retry budget, the same shape as the mermaid flow on Elasticsearch’s optimistic-concurrency page. An atomic inc modifier sidesteps the loop entirely for a plain counter, since the increment is applied server-side against whatever value is currently stored, with no client-supplied version needed.

A nested (or child) document models a parent/child relationship — an order and its line items, a blog post and its comments — as one indexing unit, so a query can filter on child fields and return (or aggregate) the matching parents without a query-time join. Solr calls indexing a parent together with all of its children in the same request block indexing; the whole block is written, replaced, and deleted as a unit.

The schema needs an indexed, non-stored root field — Solr fills it in automatically with the root document’s own id on every document in the block — and an optional nest_path field that lets Solr reconstruct the exact nesting shape (rather than just a flat parent/children list) on re-fetch.

Index children either as named pseudo-fields (each child keeps a role you can target directly) or as an anonymous childDocuments array (simpler, but the children are indistinguishable by role at query time):

Querying back across the block uses the Block Join query parsers — \{!child of=…​} to go from a matched parent down to its children, \{!parent which=…​} to go from a matched child back up to its parent — plus a [child] document transformer in fl to fold matching children back into the parent result. Query parsers covers both parsers' syntax in depth. Deleting or updating a parent document affects the whole block; splitting a shard that holds nested documents needs the block kept together, which Indexing Nested Documents covers along with the uniqueness rule every id in a block must still satisfy (every id, parent or child, is unique across the whole collection, not just within its block).

The signature update request processor (URP) computes a hash — a signature — over one or more fields of each incoming document and either rejects the document as a duplicate or overwrites the prior one that shares the same signature, instead of indexing both. It is wired into an update request processor chain in solrconfig.xml, not passed as a request parameter:

fields names what gets hashed (omit it to hash the whole document); signatureField is where the resulting hash is stored (declare it in the schema); overwriteDupes (default true) makes a duplicate replace the earlier document rather than fail; signatureClass picks the hash — Lookup3Signature (fast, order-sensitive over the listed fields), MD5Signature (a stronger, order-sensitive hash), or TextProfileSignature (near-duplicate text detection, tolerant of minor differences). Route writes through the chain with update.chain:

A schema or solrconfig.xml change (a new field, a retyped analyzer, a different uniqueKey) only takes effect for documents indexed after the change — existing documents keep whatever the old configuration produced until they are reindexed. Solr’s own migration guidance is deliberately simple and leaves the actual document-fetch/resend loop to you or your indexing pipeline:

Whichever strategy you use, an alias-based cutover is what lets a reindex run against a live, serving collection instead of requiring a maintenance window — Collections & configsets covers creating and retargeting aliases, and Indexing & updates covers the commit/soft-commit tuning that makes a bulk reindexing job itself fast.