lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael <solrco...@gmail.com>
Subject Re: Default query parameter for one core
Date Mon, 12 Oct 2009 17:05:20 GMT
OK, a hacky but working solution to making one core shard to all
others: have the default parameter *name* vary, so that one core gets
"&shards=foo" and all other cores get "&dummy=foo".

# solr.xml
<solr ...>
<property name="shardsKey" value="dummy" />
<property name="shardsValue" value="" />
<cores ...>
  <core name="core0" instanceDir="./">
    <property name="shardsKey" value="shards" />
    <property name="shardsValue" value="localhost:9990/solr/core1,..."/>
  </core>
  <core name="core1" instanceDir="./" dataDir="/search/1"/>
   ...
</cores>
</solr>

# solrconfig.xml
<requestHandler ...>
  <list name="defaults">
    <str name="${shardsKey}">${shardsValue}</str>
    ...

Michael

On Mon, Oct 12, 2009 at 12:00 PM, Michael <solrcoder@gmail.com> wrote:
> Thanks for your input, Shalin.
>
> On Sun, Oct 11, 2009 at 12:30 AM, Shalin Shekhar Mangar
> <shalinmangar@gmail.com> wrote:
>>> - I can't use a variable like ${shardsParam} in a single shared
>>> solrconfig.xml, because the line
>>>    <str name="shards">${shardsParam}</str>
>>>  has to be in there, and that forces a (possibly empty) &shards
>>> parameter onto cores that *don't* need one, causing a
>>> NullPointerException.
>>>
>>>
>> Well, we can fix the NPE :)  Please raise an issue.
>
> The NPE may be the "correct" behavior -- I'm causing an empty &shards=
> parameter, which doesn't have a defined behavior AFAIK.  The
> deficiency I was pointing out was that using ${shardsParam} doesn't
> help me achieve my real goal, which is to have the entire <str> tag
> disappear for some shards.
>
>>> So I think my best bet is to make two mostly-identical
>>> solrconfig.xmls, and point core0 to the one specifying a &shards=
>>> parameter:
>>>    <core name="core0" config="core0_solrconfig.xml"/>
>>>
>>> I don't like the duplication of config, but at least it accomplishes my
>>> goal!
>>>
>>>
>> There is another way too. Each plugin in Solr now supports a configuration
>> attribute named "enable" which can be true or false. You can control the
>> value (true/false) through a variable. So you can duplicate just the handle
>> instead of the complete solrconfig.xml
>
> I had looked into this, but thought it doesn't help because I'm not
> disabling an entire plugin -- just a <str> tag specifying a default
> parameter to a <requestHandler>.  Individual <str> tags don't have an
> "enable" flag for me to conditionally set to false.  Maybe I'm
> misunderstanding what you're suggesting?
>
> Thanks again,
> Michael
>

Mime
View raw message