The best use case I see for atomic updates typically involves avoid transmission of large documents for small field updates. If you are updating a "readCount" field of a PDF document that is 1MB in size you will avoid resending the 1MB PDF document's data in order to increment the "readCount" field.
If, instead, we're talking about 5K database records then there's plenty of argument to be made that the whole document should just be retransmitted and thus avoid the (potentially) unnecessary cost of storing all fields. As in everything, we face compromises…the question is which one better suits your needs. On Oct 10, 2013, at 5:07 AM, Erick Erickson <erickerick...@gmail.com> wrote: > bq: so what is the point of having atomic updates if > i need to update everything? > > _nobody_ claims this is ideal, it does solve a certain use-case. > We'd all like like true partial-updates that didn't require > stored fields. > > The use-case here is that you don't have access to the > system-of-record so you don't have a choice. > > See the JIRA about "stacked segments" for update without > storing fields work. > > Best, > Erick > > On Thu, Oct 10, 2013 at 12:09 AM, Shawn Heisey <elyog...@elyograg.org> wrote: >> On 10/9/2013 8:39 PM, deniz wrote: >>> Billnbell wrote >>>> You have to update the whole record including all fields... >>> >>> so what is the point of having atomic updates if i need to update >>> everything? >> >> If you have any regular fields that are not stored, atomic updates will >> not work -- unstored field data will be lost. If you have copyField >> destination fields that *are* stored, atomic updates will not work as >> expected with those fields. The wiki spells out the requirements: >> >> http://wiki.apache.org/solr/Atomic_Updates#Caveats_and_Limitations >> >> An atomic update is just a shortcut for "read all existing fields from >> the original document, apply the atomic updates, and re-insert the >> document, overwriting the original." >> >> Thanks, >> Shawn >>
