{"id":741,"date":"2020-03-23T04:12:02","date_gmt":"2020-03-23T04:12:02","guid":{"rendered":"https:\/\/www.aeologic.com\/blog\/?p=741"},"modified":"2020-03-23T04:12:02","modified_gmt":"2020-03-23T04:12:02","slug":"all-about-indexing-and-basic-data-operations-part-4-ultimate-solr-guide","status":"publish","type":"post","link":"https:\/\/www.aeologic.com\/blog\/all-about-indexing-and-basic-data-operations-part-4-ultimate-solr-guide\/","title":{"rendered":"All About Indexing and Basic Data Operations – Part 4 – Ultimate Solr Guide"},"content":{"rendered":"

Hello, Everyone! Today we are here with another post to further our discussion about basic indexing operations in solr.\u00a0 Another basic need one faces in the indexed doc in solr is to change the doc contents. Solr supports three approaches to update a document with varied necessity.<\/p>\n

\n

Updating Parts of Documents<\/h1>\n

The first is\u00a0atomic updates<\/a><\/em>. This approach allows changing only one or more fields of a document without having to re-index the entire document.<\/p>\n

The second approach is known as\u00a0in-place updates<\/a><\/em>. This approach is similar to atomic updates (is a subset of atomic updates in some sense), but can be used only for updating single valued non-indexed and non-stored docValue-based numeric fields.<\/p>\n

The third approach is known as\u00a0optimistic concurrency<\/a><\/em>\u00a0or\u00a0optimistic locking<\/em>. It is a feature of many NoSQL databases, and allows conditional updating a document based on its version. This approach includes semantics and rules for how to deal with version matches or mis-matches.<\/p>\n

\n
\n
\n

Atomic Updates (and in-place updates) and Optimistic Concurrency may be used as independent strategies for managing changes to documents, or they may be combined: you can use optimistic concurrency to conditionally apply an atomic update.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Atomic Updates<\/h2>\n

Solr supports several modifiers that atomically update values of a document. This allows updating only specific fields, which can help speed indexing processes in an environment where speed of index additions is critical to the application.<\/p>\n

\n
\n

To use atomic updates, add a modifier to the field that needs to be updated. The content can be updated, added to, or incrementally increased if the field has a numeric type.<\/p>\n<\/div>\n

\n
\n
set<\/code><\/dt>\n
Set or replace the field value(s) with the specified value(s), or remove the values if ‘null’ or empty list is specified as the new value.<\/p>\n
\n

May be specified as a single value, or as a list for multiValued fields.<\/p>\n<\/div>\n<\/dd>\n

add<\/code><\/dt>\n
Adds the specified values to a multiValued field. May be specified as a single value, or as a list.<\/dd>\n
add-distinct<\/code><\/dt>\n
Adds the specified values to a multiValued field, only if not already present. May be specified as a single value, or as a list.<\/dd>\n
remove<\/code><\/dt>\n
Removes (all occurrences of) the specified values from a multiValued field. May be specified as a single value, or as a list.<\/dd>\n
removeregex<\/code><\/dt>\n
Removes all occurrences of the specified regex from a multiValued field. May be specified as a single value, or as a list.<\/dd>\n
inc<\/code><\/dt>\n
Increments a numeric value by a specific amount. Must be specified as a single numeric value.<\/dd>\n<\/dl>\n<\/div>\n
\n

Field Storage<\/h3>\n
\n

The core functionality of atomically updating a document requires that all fields in your schema must be configured as stored (stored=\"true\"<\/code>) or docValues (docValues=\"true\"<\/code>) except for fields which are\u00a0<copyField\/><\/code>\u00a0destinations, which must be configured as\u00a0stored=\"false\"<\/code>. Atomic updates are applied to the document represented by the existing stored field values. All data in copyField destinations fields must originate from ONLY copyField sources.<\/p>\n<\/div>\n

\n

If\u00a0<copyField\/><\/code>\u00a0destinations are configured as stored, then Solr will attempt to index both the current value of the field as well as an additional copy from any source fields. If such fields contain some information that comes from the indexing program and some information that comes from copyField, then the information which originally came from the indexing program will be lost when an atomic update is made.<\/p>\n<\/div>\n

\n

There are other kinds of derived fields that must also be set so they aren\u2019t stored. Some spatial field types, such as BBoxField and LatLonType, use derived fields. CurrencyFieldType also uses derived fields. These types create additional fields which are normally specified by a dynamic field definition. That dynamic field definition must be not stored, or indexing will fail.<\/p>\n<\/div>\n

Example Updating Part of a Document<\/h3>\n
\n

If the following document exists in our collection:<\/p>\n

\"\"<\/p>\n

And we apply the following update command:<\/p>\n

\"\"<\/p>\n

The resulting document in our collection will be:<\/p>\n

\"\"<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n

In-Place Updates<\/h2>\n

 <\/p>\n

\n
\n

In-place updates are very similar to atomic updates; in some sense, this is a subset of atomic updates. In regular atomic updates, the entire document is re-indexed internally during the application of the update. However, in this approach, only the fields to be updated are affected and the rest of the documents are not re-indexed internally. Hence, the efficiency of updating in-place is unaffected by the size of the documents that are updated (i.e., number of fields, size of fields, etc.). Apart from these internal differences, there is no functional difference between atomic updates and in-place updates.<\/p>\n<\/div>\n

\n

An atomic update operation is performed using this approach only when the fields to be updated meet these three conditions:<\/p>\n<\/div>\n

\n