Re: Timestamp field is changed on update

[Isaac Hebsh <is...@gmail.com>]

Hoss Man suggested a wonderful solution for this need:
Always set update="add" to the field you want to keep (is exists), and use
FirstFieldValueUpdateProcessorFactory in the update chain, after
DistributedUpdateProcessorFactory (so the AtomicUpdate will add the
existing field before, if exists).

This solution exactly covers my case. Thank you!


On Wed, Feb 20, 2013 at 11:33 PM, Isaac Hebsh <is...@gmail.com> wrote:

> Nobody responded my JIRA issue :(
> Should I commit this patch into SVN's trunk, and set the issue as Resolved?
>
>
> On Sun, Feb 17, 2013 at 9:26 PM, Isaac Hebsh <is...@gmail.com>wrote:
>
>> 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 <
>> arafalov@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 <
>>> wunder@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
>>>
>>
>>
>