lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: DEFAULT_CORE
Date Thu, 14 Jan 2010 18:46:13 GMT

: 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


Mime
View raw message