Thanks, Mike,
we have discussed something similar with steffkes on IRC today, where I
said: "some programmatic convenience would be great of course. But I could
in principle imagine having two versions of solrconfig.xml and swapping
them followed by a core reload. It just sounds a bit scary to me."
But now, after pondering a bit more over it, I start to get inclined
towards "fiddling with sending dummy documents with certain fields that
will tell the update component to either call another update component or
proceed normally"
another = custom updater
normally = default updater
More ideas are of course welcome!
Dmitry
On Mon, Nov 3, 2014 at 2:41 PM, Michael Sokolov <
msoko...@safaribooksonline.com> wrote:
> Just to get the obvious sledgehammer solution out of the way - upload a
> new, edited solrconfig.xml with the default changed, and reload the core.
>
> -Mike
>
>
>
> On 11/3/14 6:28 AM, Dmitry Kan wrote:
>
>> Hello solr fellows,
>>
>> I'm working on a project that involves using two update chains. One
>> default
>> chain is used most of the time and another one custom is used
>> sporadically.
>>
>> The default update chain is called automatically without action needed
>> (well, that's why it is default).
>>
>> The custom pipeline can be switched on using update.chain http parameter,
>> like so:
>>
>> [code]
>> UpdateRequest updateRequest = new UpdateRequest();
>> updateRequest.setCommitWithin(10000);
>> updateRequest.setParam("update.chain", "customupdatechain");
>> updateRequest.add(solrDoc);
>> updateRequest.process(solrServer);
>> [/code]
>>
>> Now I have a new requirement: be able to install the custom chain as the
>> default update chain such that any client that is sending data in will get
>> it processed via the custom chain and not the default chain. And this
>> should happen seamlessly to the client, i.e. no parameter change needed.
>>
>> Is this possible with the current state of the Solr core / collection api
>> or some other method?
>>
>>
>
--
Dmitry Kan
Luke Toolbox: http://github.com/DmitryKey/luke
Blog: http://dmitrykan.blogspot.com
Twitter: http://twitter.com/dmitrykan
SemanticAnalyzer: www.semanticanalyzer.info
