You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Yonik Seeley <yo...@lucidimagination.com> on 2010/01/14 18:17:33 UTC
DEFAULT_CORE
The current way of allowing the omission of a core name in the URL is
to name the core DEFAULT_CORE.
While this functionality is great, and allows a multi-core setup to be
back compat with existing URLs, if someone does want to also refer to
the core by it's proper name, it looks pretty ugly. This also impacts
SolrCloud, since the core name is used as the collection name by
default (and a collection name of DEFAULT_CORE is... ugly).
So I'd propose that we either:
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"
It seems like #1 would be preferable... thoughts?
-Yonik
http://www.lucidimagination.com
Re: DEFAULT_CORE
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Thu, Jan 14, 2010 at 12:22 PM, Mark Miller <ma...@gmail.com> wrote:
> I think we should do both - allow marking any core as the default and
> change our single core example solr.xml to use collection1 rather than
> DEFAULT_CORE.
+1
-Yonik
http://www.lucidimagination.com
Re: DEFAULT_CORE
Posted by Mark Miller <ma...@gmail.com>.
Yonik Seeley wrote:
> The current way of allowing the omission of a core name in the URL is
> to name the core DEFAULT_CORE.
> While this functionality is great, and allows a multi-core setup to be
> back compat with existing URLs, if someone does want to also refer to
> the core by it's proper name, it looks pretty ugly. This also impacts
> SolrCloud, since the core name is used as the collection name by
> default (and a collection name of DEFAULT_CORE is... ugly).
>
> So I'd propose that we either:
> 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"
>
> It seems like #1 would be preferable... thoughts?
>
> -Yonik
> http://www.lucidimagination.com
>
I think we should do both - allow marking any core as the default and
change our single core example solr.xml to use collection1 rather than
DEFAULT_CORE.
--
- Mark
http://www.lucidimagination.com
Re: DEFAULT_CORE
Posted by Mark Miller <ma...@gmail.com>.
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
Re: DEFAULT_CORE
Posted by Chris Hostetter <ho...@fucit.org>.
: 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