First off: I want to make sure every one is very clear that the entire
premise of this thread is asking about behavior that is not officially
supported or recommened -- that's why it's under-specified in the
documentation. (in the same way that asking something like "what happens
if i send a JSON query inside of a JSON update?" isn't specified)
What Dmitri is describing is the "actual behavior" given un-supported
input -- Solr's behavior of (essentially) "do the best we can
with what you've given us" (as opposed to a hard failure) is largely just
due to quirks of how atomic updates are implemented, with a dash of "let's
avoid breaking things for people who might have come to rely on this
behavior"
By all means, feel free to submit a patch with a suggested doc update that
says something like: "NOTE: mixing atomic updates with plain field updates
is not recommended and may have unexpected behavior"
Second: This comment here still seems to be completley overlooking
Dmitri's point about *existing* fields in the index...
: > So in your example, say doc with id “foo” has 10 fields in the index, then
...
: > { "id" : "foo", "bar" : { "set" : "baz" }, "bleh" : "schmeh" }
:
: If what you say is true, then this is equivalent to a full upsert and the
: "partial update" instruction is redundant. My reading of the fine manual is
The presence of an atomic update modifier (set in this example) on any
field(s) in the add document command, instructs solr that the *entire*
command should be treated as an atomic update. All existing fields in the
document (unless explicitly mentioned in the add document command) should
be left alone.
Claiming "the 'partial update' instruction is redundant" implies a
missunderstanding of the end state of these two sequences...
{ "id" : "1", "aaa" : "xxx", "bbb" : "bbb" }
{ "id" : "1", "aaa" : { "set":"yyy"} }
{ "id" : "2", "aaa" : "xxx", "bbb" : "bbb" }
{ "id" : "2", "aaa" : "yyy" }
in both cases, the document will be updated to use "aaa=yyy" but only doc
#1 will keep it's "bbb=bbb"
Effectively: mixing in "plain fields" with atomic updates makes the "plain
fields" act like "set" commands -- but there must be at least one field
with an atomic-update modifier for solr to reconginze that you don't want
to *completely* replace the entire document.
Third: this comment...
: "partial update" instruction is redundant. My reading of the fine manual is
: that partial update only reindexes the single docvalues field, which is not
: the right thing to do in this case, so it has to be ignored.
...implies a confusion between "atomic updates" and "in-place updates"
Atomic Updates are only in-place updates if all of the specified fields to
be modified cab be modified "in place" ...
https://solr.apache.org/guide/solr/latest/indexing-guide/partial-document-updates.html#in-place-updates
-Hoss
http://www.lucidworks.com/
