lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Rowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-4478) Allow cores to specify a named config set
Date Wed, 17 Jul 2013 14:34:50 GMT

    [ https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711135#comment-13711135
] 

Steve Rowe commented on SOLR-4478:
----------------------------------

{quote}
bq. If two cores are sharing a config set with a managed schema, and someone makes changes
to the schema under one of them, does the other core pick up the changes as well?

I think it should... It's one logical schema, just as if you changed it on disk and reloaded/restarted
the cores. One physical schema == one logical schema. It also already effectively works this
way in Cloud mode.
{quote}

+1

In my original commit for SOLR-3251, I had code to handle shared + mutable schemas, but it
wasn't all hooked up properly or tested, and with named config sets in play, I haven't pursued
it.

For local shared + mutable schema, I think we have two choices:

# Each named config set has a single shared in-memory representation, in addition to a single
shared persisted representation.
# Each core has its own private in-memory representation, updated when the shared persisted
representation is updated.

#2 nullifies the utility of shared schemas, so it's not really an option, IMHO.

                
> 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
>         Attachments: SOLR-4478.patch, SOLR-4478.patch
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message