Erick Erickson created SOLR-4478:
------------------------------------
Summary: Allow cores to specify a named config set
Key: SOLR-4478
URL: https://issues.apache.org/jira/browse/SOLR-4478
Project: Solr
Issue Type: Improvement
Affects Versions: 4.2, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Part of moving forward to "the new way", after SOLR-4196 etc... I propose an
additional parameter specified on the <core> node in solr.xml or as a parameter
in the "discovery" mode core.properties file, call it configSet, where the
value provided is a path to a directory, either absolute or relative. Really,
this is as though you copied the conf directory somewhere to be used by more
than one core.
Straw-man: There will be a directory <solr_home>/configsets which will be the
default. If the configSet parameter is, say, "myconf", then I'd expect a
directory named "myconf" to exist in <solr_home>/configsets, which would look
something like
<solr_home>/configsets/myconf/schema.xml
solrconfig.xml
stopwords.txt
velocity
velocity/query.vm
etc.
If multiple cores used the same configSet, schema, solrconfig etc. would all be
shared (i.e. shareSchema="true" would be assumed). I don't see a good use-case
for _not_ sharing schemas, so I don't propose to allow this to be turned off.
Hmmm, what if shareSchema is explicitly set to false in the solr.xml or
properties file? I'd guess it should be honored but maybe log a warning?
Mostly I'm putting this up for comments. I know that there are already thoughts
about how this all should work floating around, so before I start any work on
this I thought I'd at least get an idea of whether this is the way people are
thinking about going.
Configset can be either a relative or absolute path, if relative it's assumed
to be relative to <solr_home>.
Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
