[jira] [Created] (SOLR-12872) Deprecate split.key parameter in SPLITSHARD API and make it easier to use

["Anshum Gupta (JIRA)" <ji...@apache.org>]

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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org