[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579558#comment-14579558
]
Gregory Chanan commented on SOLR-7570:
--
bq. 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
as far as I understand it, this suggestion is addressing tomas' bullet above:
{code}
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. We should keep this as a way to edit shared
configsets, users would for example, upload a new solrconfig.xml and then touch
the configset. This should reload all collections using that configset as we do
now.
{code}
i.e. you need a place to share mutable configs. It seems cleaner to have a
separate ConfigSet API, i.e. REST calls to, say, /configs/MySharedConfig rather
than to alias collection-specific APIs. The later just gets us back to the
case we are in now, where collection-specific APIs can result in changes
outside the collection. That is confusing IMO.
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571347#comment-14571347
]
Mark Miller commented on SOLR-7570:
---
bq. But we have to find a sane way to share mutable configs and it is an
extremely common usecase
+1 to that sentiment.
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568707#comment-14568707
]
Tomás Fernández Löbbe commented on SOLR-7570:
-
bq. But we have to find a sane way to share mutable configs and it is an
extremely common usecase
I agree with what I think Alan is saying here. In summary:
* ConfigSets are all shareable meaning, you create a collection using a
configset, it doesn't matter if there are other collections already using it or
not.
* Changes made via config APIs to a collection are specific to the collection
where the request was done. Changes are stored in
/collections/$COLLECTION_NAME/conf.
* 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. We should keep this as a way to edit shared
configsets, users would for example, upload a new solrconfig.xml and then touch
the configset. This should reload all collections using that configset as we do
now.
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568970#comment-14568970
]
Noble Paul commented on SOLR-7570:
--
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567249#comment-14567249
]
Alan Woodward commented on SOLR-7570:
-
I think that's making things overcomplicated. Whether or not a specific config
setting is updated via overlay or via XML file changes is an implementation
detail. I'd rather we just made configs immutable (at least through this API),
and overlays always written to the collection-specific config. If you want to
update the overlay for multiple collections, you could use aliases, or set
collection=coll1,coll2 etc on the query?
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568523#comment-14568523
]
Noble Paul commented on SOLR-7570:
--
bq.I think that's making things overcomplicated.
I agree with you . But we have to find a sane way to share mutable configs and
it is an extremely common usecase
Here is another suggestion
Every collection , by default, stores the mutable stuff at
{{/collections/$COLLECTION_NAME/conf}} . Alternately, it should be possible to
specify the ZNODE where you would store the mutable stuff during collection
creation. This enables the user to specify a common ZNODE for multiple
collections
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14564398#comment-14564398
]
Alan Woodward commented on SOLR-7570:
-
bq. will the LOCAL changes make sense for SolrCloud mode?
I was thinking it might come in useful for things like PeerSync, or possibly
per-core roles.
I'll change the collection-specific znode to conform with the existing setup.
Back-compatibility shouldn't be a problem, as existing installations will have
their overlays read from the shared config, up until they make a change, at
which point an overlay will be written to the collection config, which takes
precedence. I still need to work out how this works with ConfListeners though.
Changes shared between collections should be done through a different API, I
think. Something like the configset API being discussed on SOLR-5955 would be
more appropriate for that.
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14564527#comment-14564527
]
Noble Paul commented on SOLR-7570:
--
bq.Changes shared between collections should be done through a different API, I
think. Something like the configset API being discussed on SOLR-5955 would be
more appropriate for that.
Those changes will be rare and I would say let them upload full files using a
config upload API
bq.Changes shared between collections should be done through a different API, I
think
Can we make it a property of the configset called shareable. We should use an
extra empty node in the conf dir called SHAREABLE , which signifies that this
configset is shareable and overlay extra can be written there . Which will
ensure that the overlay etc will be written to the configset dir itself.
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563258#comment-14563258
]
Noble Paul commented on SOLR-7570:
--
* Do we have a plan on the backcompat ? What happens to the existing
configoverlay.json etc ?
* What happens if I really wish to store the config changes shared between
collections. It is a common usecase
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
[jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563190#comment-14563190
]
Tomás Fernández Löbbe commented on SOLR-7570:
-
I like the patch, the changes in ZkSolrResourceLoader look great. One question
in my mind is, will the LOCAL changes make sense for SolrCloud mode? when would
one want to change a single core? Also, looks like the collection-specific
znode is /$COLLECTION_NAME/config, we currently have
/collections/$COLLECTION_NAME/... for stuff like state.json, would it make
more sense for the collection specific config to be in
/collections/$COLLECTION_NAME/config/ ?
I do think that this may conflict with the discussions going on in SOLR-5955
and email list about mutable/immutable configsets and collection specific
changes... I think we should make a decision before committing any more code
related to this.
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
