Hello Yonik, On Thu, 2011-01-27 at 08:01 -0500, Yonik Seeley wrote: > Making it easy for clients I think is key... one should be able to > update any node in the solr cluster and have solr take care of the > hard part about updating all relevant shards. This will most likely > involve an update processor. This approach allows all existing update > methods (including things like CSV file upload) to still work > correctly. > > Also post.jar is really just for testing... a command-line replacement > for "curl" for those who may not have it. It's not really a > recommended way for updating Solr servers in production.
OK, I've abandoned the post.jar tool idea in favour of a DistributedUpdateRequestProcessor class (I've been looking into other classes like UpdateRequestProcessor, RunUpdateRequestProcessor, SignatureUpdateProcessorFactory, and SolrQueryRequest to see how they are used/what data they store - hence why I've taken some time to respond). My big question now is that is it necessary to have a Factory class for DistributedUpdateRequestProcessor? I've seen this lots of times, as in RunUpdateProcessorFactory (where the factory class was only a few lines of code) to SignatureUpdateProcessorFactory? At first I was thinking it would be a good design idea to include it in (in a generic sense), but then I thought harder and I thought that the DistributedUpdateRequestHander would only be running once, taking in all the requests, so it seems sort of pointless to write one in. That is my "burning" question for now. I have got a few more questions, but I'm sure that when I look further into the code, I'll either have more or all of my questions are answered. Many thanks! Soheb Mahmood --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
