[
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: [email protected]
For additional commands, e-mail: [email protected]
