Differences between revisions 5 and 6
Revision 5 as of 2016-05-31 16:26:09
Size: 3552
Editor: ShawnHeisey
Comment: More clarity on the fact that copyField destinations must only use data from copyField.
Revision 6 as of 2016-08-01 21:04:26
Size: 2937
Comment: Add header for content moved to CWIKI
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
{{{#!wiki important
This page exists for the Solr Community to share Tips, Tricks, and Advice about
[[https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents#UpdatingPartsofDocuments-AtomicUpdates|Atomic Updates]].

Reference material previously located on this page has been migrated to the
[[https://cwiki.apache.org/solr/|Official Solr Reference Guide]].
If you need help, please consult the Ref Guide for the version of Solr you are using
for the specific details about using [[https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents#UpdatingPartsofDocuments-AtomicUpdates|this feature]].

If you'd like to share information about how you use this feature, please [[FrontPage#How_to_edit_this_Wiki|add it to this page]].
/* cwikimigrated */
}}}

Line 5: Line 19:
Atomic Updates is a new feature in Solr 4.0 that allows you to update on a field level rather than on a document level (In previous versions). This means that you can update individual fields without having to send the entire document to Solr with the un-updated fields values. Internally Solr re-adds the document to the index with the updated fields. Atomic Updates is a feature added in Solr 4.0 that allows you to update on a field level rather than on a document level (In previous versions). This means that you can update individual fields without having to send the entire document to Solr with the un-updated fields values. Internally Solr re-adds the document to the index with the updated fields.
Line 9: Line 23:
= Available Modifiers =

 * {{{set}}} – sets or replaces a particular value, or remove the value if {{{null}}} is specified as the new value. <!> Note: In the case of multi-valued fields if {{{null}}} is specified on {{{set}}} all the values in the field are removed. See [[https://issues.apache.org/jira/browse/SOLR-3862|SOLR-3862]]
 * {{{add}}} – adds an additional value to a multi-valued field
 * {{{inc}}} – increments a numeric value by a specific amount

Example syntaxes...

 * [[UpdateJSON#Solr_4.0_Example | Update JSON Example]]
 * [[UpdateXmlMessages#Optional_attributes_for_.22field.22 | Update XML Example]]
Line 21: Line 24:

== Stored Values ==

The core functionality of atomically updating a document requires that all fields in your SchemaXml must be configured as {{{stored="true"}}} except for fields which are {{{<copyField/>}}} destinations -- which must be configured as {{{stored="false"}}}. This is because the atomic updates are applied to the document represented by the existing stored field values. This means there another requirement related to copyField destinations: All data in these fields must originate from ''ONLY'' copyField sources. 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 likely be lost when an atomic update is made.

This page exists for the Solr Community to share Tips, Tricks, and Advice about Atomic Updates.

Reference material previously located on this page has been migrated to the Official Solr Reference Guide. If you need help, please consult the Ref Guide for the version of Solr you are using for the specific details about using this feature.

If you'd like to share information about how you use this feature, please add it to this page.

<!> Solr4.0

Atomic Updates

Atomic Updates is a feature added in Solr 4.0 that allows you to update on a field level rather than on a document level (In previous versions). This means that you can update individual fields without having to send the entire document to Solr with the un-updated fields values. Internally Solr re-adds the document to the index with the updated fields.

Caveats and Limitations

Update Log

An <updateLog/> must be configured in your solrconfig.xml in order for atomic document updates to be used. This is neccessary to ensure that the update instructions are applied to the most recently indexed version of the document -- even if that version has not yet been commited (just like RealTimeGet).

DistributedUpdateRequestProcessorFactory

To improve performance in typical installations, atomic document updates are processed during execution of the DistributedUpdateRequestProcessor. By default all update chains have the DistributedUpdateRequestProcessorFactory inserted into them just prior to the RunUpdateProcessorFactory and most users won't be afected by this implementation detail, but there are two situations where it might affect you...

Using Update Processors that Modify Documents

If you use UpdateRequestProcessors to modify document values when indexing, these should be placed after the DistributedUpdateRequestProcessorFactory in your update chain to ensure they see the fully populated SolrInputDocument with all field values when an atomic document update request is recieved.

Disabling DistributedUpdateRequestProcessorFactory

If you have disabled DistributedUpdateRequestProcessorFactory by adding your own DistributingUpdateProcessorFactory (or NoOpDistributingUpdateProcessorFactory) to your update chain, then atomic document updates are not supported

References

Atomic_Updates (last edited 2016-08-01 21:04:26 by CassandraTargett)