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

Alan Woodward commented on SOLR-7570:
-------------------------------------

bq. What I'm suggesting is make the mutable conf location configurable on a per 
collection basis

OK, that seems reasonable.

There are a few moving parts here, so what I'd like to do is commit the current 
patch with its changes to SolrResourceLoader, and then open new issues for 
moving individual features to the new API:
* Config overlays
* Mutable schema
* Managed resources in general (I think this may supersede the StorageIO 
interface)

Noble's idea for configurable config locations can be in a followup issue as 
well.

> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to