[
https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381323#comment-16381323
]
Peter Rusko commented on SOLR-11960:
------------------------------------
{quote}BTW for this issue I personally would have chosen to store collection
properties on the state.json for the collection rather than put this somewhere
else. Consider all the other internal properties which are already in
state.json (e.g. replicationFactor etc.). Was this considered? Why not? Pros
are simplicity of backup and no need to delete with collection deletion, and
using the same watcher mechanism?
{quote}
Yes, I considered it. There are two reasons for choosing a separate json. First
the frequency of the change is different. Collection properties would change
way less frequently than state.json and not parsing out the properties blob on
every state change seemed the right way to go. But more importantly, state.json
changes should go via the overseer, which seemed to be a bit of an overkill
here.
> Add collection level properties
> -------------------------------
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Peter Rusko
> Assignee: Tomás Fernández Löbbe
> Priority: Major
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch,
> SOLR-11960.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining
> properties that affect a single collection. Collection properties could be
> stored in a single zookeeper node per collection, making it possible to
> trigger zookeeper watchers for only those Solr nodes that have cores of that
> collection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
