Quick clarification, when I say you can't sub-class the DistributedUpdateProcessor that is in the context of attempting to override the default merging functionality in the getUpdatedDocument method (which is package-private and not overridable from a solr-plugins classpath loader) but also code along the way uses the private constructor of the inner RequestReplicationTracker class which is required by a call to the SolrCmdDistributor.
-Steve On Wed, Oct 1, 2014 at 5:51 PM, Steve Davids <[email protected]> wrote: > 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 >
