[
https://issues.apache.org/jira/browse/SOLR-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534048#comment-14534048
]
Noble Paul edited comment on SOLR-7507 at 5/8/15 8:03 AM:
----------------------------------------------------------
bq.The config api seems to configure core properties, not collection properties.
In does not matter if you do not share config . Your usecase fits into user
props. It was designed for this purpose. Can you tell me any disadvantages of
using user props ?
bq.We do not use it, because our config does not change during runtime.
It can't be a generic enough usecase . Most people will end up changing
variables sometime during the lifetime of the collection
bq.But I want to change the properties of collections which all base on the
same config set.
If you change one of the collections it will reflect on all collections using
the same configset
was (Author: noble.paul):
bq.The config api seems to configure core properties, not collection properties.
In does not matter if you do not share config . Your usecase fits into user
props. It was designed for this purpose. Can you tell me any disadvantages of
using user props ?
bq.We do not use it, because our config does not change during runtime.
It can't be a generic enough usecase . Most people will end up changing
variables sometime during the lifetime of the collection
> Collection specific config for SolrCloud
> ----------------------------------------
>
> Key: SOLR-7507
> URL: https://issues.apache.org/jira/browse/SOLR-7507
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Affects Versions: 5.1
> Reporter: Markus Heiden
> Priority: Minor
> Labels: patch
> Attachments: SolrCloudCollectionConfig.patch
>
>
> SolrCloud uses the collection abstraction and propagates to not think of
> cores. But currently the collection properties are just stored as core
> properties of the created cores. These won't get propagated to new nodes
> automatically. This is counter-intuitive.
> This patch adds the possibility to add collection specific config files.
> These are put under the collection node in zookeeper. The resolution order
> for config file accesses is now: 1) collection node, 2) config set node, 3)
> classpath. Notice that the filesystem fallback (default:
> conf/solrcore.properties) has been removed for SolrCloud mode.
> This allows for having one generic config set being used for different
> collections which just differ in their solrcore.properties. Furthermore the
> solrcore.properties need no more to exist in the filesystem but are
> distributed via zookeeper as it should be (IMO).
> If you like this patch, I will add a patch for ZkCLI which allows the upload
> of config files for a collection in the linkconfig command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]