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

Noble Paul edited comment on SOLR-7570 at 6/2/15 11:51 AM:
-----------------------------------------------------------

I guess you guys are missing the point here. What I'm suggesting is make the 
mutable conf location configurable on a per collection basis. By default (if no 
extra param is passed) it will be {{/collections/$COLLECTION_NAME/conf}} . This 
will enable users to reuse mutable conf too. For example , when I create a 
collection I can specify {{mutableconfdir=/collections/commonConfDir/conf}} and 
every collection which has the same property will share the same node for 
mutable configs

This is common where you have one collection per user. You expect the config to 
be exactly identical for each user. I wish to use the schema API to change 
schema for all users at once . 

We are in agreement reagarding everything else.

bq.Changes to configsets need a different API, or file upload. If I remember 
correctly, collections are watching the configset znode, and may be reloaded 
after a watch is triggered.

Not yet, 
IIRC It only check for the mutable stuff . But, adding that check is trivial

The idea is to discourage users from editing files. They are error prone and 
dangerous and we want everyone to use the config APIs as much as possible




was (Author: noble.paul):
I guess you guys are missing the point here. What I'm suggesting is make the 
mutable conf location configurable on a per collection basis. By default it 
will be {{/collections/$COLLECTION_NAME/conf}} . This will enable users to 
reuse mutable conf too. For example , when I create a collection I can specify 
{{mutableconfdir=/collections/commonConfDir/conf}} and every collection will 
have the same property

This is common where you have one collection per user. You expect the config to 
be exactly identical for each user. I wish to use the schema API to change 
schema for all users at once . 

We are in agreement reagarding everything else.

bq.Changes to configsets need a different API, or file upload. If I remember 
correctly, collections are watching the configset znode, and may be reloaded 
after a watch is triggered.

Not yet, 
IIRC It only check for the mutable stuff . But, adding that check is trivial

The idea is to discourage users from editing files. They are error prone and 
dangerous and we want everyone to use the config APIs as much as possible



> Config APIs should not modify the ConfigSet
> -------------------------------------------
>
>                 Key: SOLR-7570
>                 URL: https://issues.apache.org/jira/browse/SOLR-7570
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Tomás Fernández Löbbe
>         Attachments: SOLR-7570.patch
>
>
> Originally discussed here: 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201505.mbox/%3CCAMJgJxSXCHxDzJs5-C-pKFDEBQD6JbgxB=-xp7u143ekmgp...@mail.gmail.com%3E
> The ConfigSet used to create a collection should be read-only. Changes made 
> via any of the Config APIs should only be applied to the collection where the 
> operation is done and no to other collections that may be using the same 
> ConfigSet. As discussed in the dev list: 
> When a collection is created we should have two things, an immutable part 
> (the ConfigSet) and a mutable part (configoverlay, generated schema, etc). 
> The ConfigSet will still be placed in ZooKeeper under "/configs" but the 
> mutable part should be placed under "/collections/$COLLECTION_NAME/…"
> [~romseygeek] suggested: 
> {quote}
> A nice way of doing it would be to make it part of the SolrResourceLoader 
> interface.  The ZK resource loader could check in the collection-specific 
> zknode first, and then under configs/, and we could add a writeResource() 
> method that writes to the collection-specific node as well.  Then all config 
> I/O goes via the resource loader, and we have a way of keeping certain parts 
> immutable.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to