Right. Without atomic updates, the client needs to fetch the document (or
rebuild it from the system of record), apply changes, and send the entire
document to Solr, including fields that haven't changed. With atomic updates,
the client sends a list of changes to Solr and the server handles the
I see what you mean now. Thanks for the example. It makes things very
clear.
I have been thinking about the explanation in the original response more.
According to that, both regular update with entire doc and atomic update
involves a delete by id followed by a add. But both the Solr reference
Take a look at this update XML:
05991
Steve McKay
Walla Walla
Python
Let's say employeeId is the key. If there's a fourth field, salary, on the
existing doc, should it be deleted or retained? With this update it will
obviously be deleted:
05991
Steve McKay
Thanks for that under-the-cover explanation.
I am not sure what you mean by "mix atomic updates with regular field
values". Can you give an example?
Thanks.
Bill
On Tue, Jul 8, 2014 at 6:56 PM, Steve McKay wrote:
> Atomic updates fetch the doc with RealTimeGet, apply the updates to the
> fe
Atomic updates fetch the doc with RealTimeGet, apply the updates to the fetched
doc, then reindex. Whether you use atomic updates or send the entire doc to
Solr, it has to deleteById then add. The perf difference between the atomic
updates and "normal" updates is likely minimal.
Atomic updates
Solr atomic update allows for changing only one or more fields of a
document without having to re-index the entire document. But what about
the case where I am sending in the entire document? In that case the whole
document will be re-indexed anyway, right? So I assume that there will be
no savi
