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
