You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Gus Heck (JIRA)" <ji...@apache.org> on 2019/02/14 13:58:00 UTC
[jira] [Commented] (SOLR-13150) Enforce a max cardinality on
category routed aliases
[ https://issues.apache.org/jira/browse/SOLR-13150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768275#comment-16768275 ]
Gus Heck commented on SOLR-13150:
---------------------------------
Elsewhere Moshe asked:
Should max cardinality have a default value, or should it be a required parameter?
I'm not sure whether it should be an optional parameter.
[~gus_heck],
WDYT?
My inclination is to make it required. The user can always set it to 99999 or whatever if they like, but then they can't complain that they wound up with 99999 collections and their overseer node going on strike. We can support -1 for fully unlimited too, but this feature is slightly dangerous without a sensible safety valve so I'd like the user to actively consider the implications and opt in to the danger. If we did default it I'd make it something small like 5-10 for safety, but most people will probably change that.
> Enforce a max cardinality on category routed aliases
> ----------------------------------------------------
>
> Key: SOLR-13150
> URL: https://issues.apache.org/jira/browse/SOLR-13150
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
> Affects Versions: master (9.0)
> Reporter: Gus Heck
> Priority: Major
>
> This ticket will add the check to enforce a (configurable) maximum number of collections in a category routed alias. The purpose of this check is to provide a safety valve to ensure that unexpected data values don't cause run-away collection creation. This check should happen within the validateRouteValue() method specified by RoutedAlias
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org