You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Anshum Gupta (JIRA)" <ji...@apache.org> on 2018/10/15 19:48:00 UTC
[jira] [Resolved] (SOLR-12872) Deprecate split.key parameter in
SPLITSHARD API and make it easier to use
[ https://issues.apache.org/jira/browse/SOLR-12872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anshum Gupta resolved SOLR-12872.
---------------------------------
Resolution: Invalid
False alarm. There is some disconnect between what the documentation says and what the code does. I'll fix the documentation as part of SOLR-5004 instead of here and leave the split.key parameter as is.
> Deprecate split.key parameter in SPLITSHARD API and make it easier to use
> -------------------------------------------------------------------------
>
> Key: SOLR-12872
> URL: https://issues.apache.org/jira/browse/SOLR-12872
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Anshum Gupta
> Assignee: Anshum Gupta
> Priority: Major
>
> While working on SOLR-5004, I realized how confusing the current SPLITSHARD API can get. Here's the current set of options to split a shard:
> # Specify split.key but not with shard name. Providing the shard name here leads to an exception
> # Specify ranges with shard name (actually the same as above) but requires the shard name
> # Not specify ranges OR split.key. This will split the specified shard into 2 from the middle of the hash range.
> split.key is just a syntactic sugar on top of the shard + ranges combination. Ideally, we can even figure out shard name from the ranges, but for the sake of consistency it perhaps makes sense to make shard name mandatory.
> I propose that we deprecate split.key and only allow 2 options:
> # shard name + ranges
> # shard name + (optional numSubShards as part of SOLR-5004). The number of sub-shards defaults to 2.
> The intention here is to simplify the API by providing fewer but more consistent and intuitive options.
--
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