: atomic updates. Here is the use-case I am looking at... I want to keep
: track of the indexed-on date which is a snapshot in time of when that
: particular document was indexed for the first time. Currently I have that
: value stored and the value is set to "NOW" as the default value in the
: schema. Now, I want to actually set this value in the update chain prior to
: the distributed index request so all replicas obtain the exact same value.
: Unfortunately there isn't a way to specify use this new "NOW" date *only*
: if the value hasn't been indexed prior, so I was thinking that this can be

There is actually, but it takes a little creative thinking...

Assume you want this field to be named 'timestamp', then you want an 
update chain that looks something like this...

  <updateRequestProcessorChain>
    <processor class="solr.TimestampUpdateProcessorFactory">
      <str name="fieldName">timestamp_tmp</str>
    </processor>
    <processor class="solr.DistributedUpdateProcessorFactory" />
    <processor class="solr.CloneFieldUpdateProcessorFactory">
      <str name="source">timestamp_tmp</str>
      <str name="dest">timestamp</str>
    </processor>
    <processor class="solr.MinFieldValueUpdateProcessorFactory">
      <str name="fieldName">timestamp</str>
    </processor>
    <processor class="solr.IgnoreFieldUpdateProcessorFactory">
      <str name="fieldName">timestamp_tmp</str>
    </processor>
    <processor class="solr.RunUpdateProcessorFactory" />
  </updateRequestProcessorChain>

...so on every doc update, a "timestamp_tmp" field will be computed on the 
initial node, then during the DistributedUpdateProcessor, when the leader 
deals with merging in existing values if the doc update is an atomic 
update, you may get an existing (older) value in the "timestamp" field.  
then (on each replica) timestamp_tmp will be cloned into timestamp, and 
the minimum (ie: oldest) value will be used.  at which point you can now 
ignore/remove timestamp_tmp from the documents.

(disclaimer: doing this all from memory, haven't verified it works as is 
... may be typos or logic ordering mistakes, but the basic gist should be 
sound)

-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to