lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Date Thu, 14 Jan 2010 18:50:39 GMT
Chris Hostetter wrote:
> : The current way of allowing the omission of a core name in the URL is
> : to name the core DEFAULT_CORE.
> 	...
> : 1) allow an optional flag in solr.xml to mark that any core is also
> : the default core
> : 2) rename DEFAULT_CORE to something nicer like "collection1"
> ...having a default="true" attribute on a <core/> in solr.xml was 
> something that was orriginally implemented, but was removed because wound 
> up causing a lot of problems and lead to a lot of edge case confusion ... 
> i don't remember all of the details off the top of me head, but even 
> at a high level i'm not clear on what the expectation would be if we had 
> an attribute like that and someone used the SWAP command where one of the 
> cores was orriginally the default, or UNLOADed the default core.
> Berhaps a better approach then a "default" property on a logical core, 
> would be a "defaultCoreName" property on the "Core Collection" object 
> itself (i can't remember what it's called) .... so *iff* that property is 
> set, and *iff* a core exists with that name/alias then that core is 
> currently the default -- but the default-ed-ness is mapped to the string, 
> not to any one specific core; and that string is used to lookup a core by 
> name.
> solr.xml configuration could look like...
>   <solr>
>     <cores adminPath="/admin/cores" defaultCoreName="core0">
>       <core name="core0" instanceDir="core0" />
>       <core name="core1" instanceDir="core1" />
>     </cores>
>   </solr>
> ...and if people felt it was worthwhile an 
> "action=SETDEFAULT&name=myCoreName" action could be added to the 
> CoreAdminHandler.
> ...i haven't thought this idea through very far to be sure it won't have 
> as many problems as a "default" attribute, but it should avoid the 
> problems we already know about.
> -Hoss
+1 - thats actually the way I was thinking it would happen - not that
each core had a default prop, but that at the container level you set a
name for the default core (as you specify above).

Essentially, it would work exactly like it does right now - except
rather than hard coding DEFAULT_CORE as the default core, you could
simply change that name to something else. And we would default to
collection1 rather than DEFAULT_CORE.

Code wise, its almost no change.

- Mark

View raw message