Thank you Alex. Atomic Update allows you to "add" new values into multivalued field, for example... It means that the original document is being read (using RealTimeGet, which depends on updateLog). There is no reason that the list of operations (add/set/inc) will not include a "create-only" operation... I think that throwing it to the client is not a good idea, and even only because the required atomicity (which is handled in the DistributedUpdateProcessor using internal locks).
There is no problem when using Atomic Update semantics on non-existent document. Indeed, it will work on stored fields only. On Sun, Feb 17, 2013 at 8:47 AM, Alexandre Rafalovitch <arafa...@gmail.com>wrote: > Unless it is an Atomic Update, right. In which case Solr/Lucene will > actually look at the existing document and - I assume - will preserve > whatever field got already populated as long as it is stored. Should work > for default values as well, right? They get populated on first creation, > then that document gets partially updated. > > But I can't tell from the problem description whether it can be > reformulated as something that fits Atomic Update. I think if the client > does not know whether this is a new record or an update one, Solr will > complain if Atomic Update semantics is used against non-existent document. > > Regards, > Alex. > P.s. Lots of conjecture here; I haven't tested exactly this use-case. > > Personal blog: http://blog.outerthoughts.com/ > LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch > - Time is the quality of nature that keeps events from happening all at > once. Lately, it doesn't seem to be working. (Anonymous - via GTD book) > > > On Sun, Feb 17, 2013 at 12:40 AM, Walter Underwood <wun...@wunderwood.org> > wrote: > > > > It is natural part of the update model for Solr (and for many other > search engines). Solr does not do updates. It does add, replace, and > delete. > > > > Every document is processed as if it was new. If there is already a > document with that id, then the new document replaces it. The existing > documents are not read during indexing. This allows indexing to be much > faster than in a relational database. > > > > wunder >
