: 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
