David Smiley commented on SOLR-11960:

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?

bq. I think it's probably less confusing the way we did it to have alias level 
metadata/props, since the time routing is at the alias level, and collections 
come and go over time

Ehh; debatable.  I think it's worse for maintenance, docs, and our users, to 
unnecessarily increase the API surface area (plus rather different plumbing 
too) by having both.  Since aliases operate in the same namespace as 
collections, I don't think of it as separate.

> 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 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

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

Reply via email to