Anshum Gupta created SOLR-12872: ----------------------------------- Summary: 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
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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org