I was curious if it would make sense to provide a "default" command for 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 simply handled by a "default" atomic update key that would only apply the value if the document that is to being merged doesn't already have a value specified. In addition to the validity of that thought, I was wondering if people would find it beneficial to allow sub-classing of the DistributedUpdateProcessorFactory (currently unable to due to inner classes) or at a minimum allow clients to specify their own merge logic implementation if they see fit.
I would be happy to provide some patches if people think these are reasonable use-cases. Thanks, -Steve
