Atomic updates allow you to update an already indexed document by giving a new field value, adding a value to the existing values on a multivalued field, or by incrementing a numeric field. Instead of giving an entire document, you supply a document that only has the fields that are to be modified in some way, and with a special modifier (described next). If Solr sees these modifiers on any field in an incoming document, then it knows this is an atomic-update to an existing document versus a new or replacement document. This is both a convenience feature, and with optimistic concurrency (described soon), allows Solr to be a credible NoSQL option.

We'll show you how this is used by way of a succinct example, and we'll use JSON this time. Note that, most fields don't just have a value but are structured to include one of several mutation modifiers. In the XML syntax, these are specified with attributes.

{"id":"mydoc",
 "price":{"set":99},
 "popularity":{"inc":20},
 "categories":{"add":["toys","games"]},
 "promo_ids":{"remove":"a123x"},
 "tags":{"remove":["free_to_try","on_sale"]}
}

The following are the key points to remember while using atomic updates:

Optimistic concurrency can be used by applications that update or replace documents to ensure that the document they are updating or replacing has not been concurrently modified by another application. This feature works by requiring a _version_ field on all documents in the index, and comparing that to a _version_ specified as part of the update command. By default, Solr's schema.xml includes a _version_ field, and this field is automatically added to each new document. Along with NRT get and atomic updates, this feature allows Solr to be used as a NoSQL database.