[
https://issues.apache.org/jira/browse/SOLR-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514651#comment-13514651
]
Michael Garski commented on SOLR-2592:
--------------------------------------
Hi Shreejay -
I have not updated my patch in a few months so it may not apply cleanly to the
latest in branch_4x. The last patch I updated is SOLR-2592_r1384367.patch. If
it does apply cleanly you can configure the shard key parser as a child of the
'config' element. Here is an example that will work with a composite unique id
delimited with underscores such as "123_abc", and the document will be hashed
based on "123". The clause section of the config will be used in a delete by
query, and in the example below the value of clause for the field "foo_field"
will be used to hash on to determine which shard the delete will be forwarded
to. If the clause is required and a delete by query is submitted by a client
the request will return an error.
{code:xml}
<shardKeyParserFactory
class="org.apache.solr.common.cloud.CompositeIdShardKeyParser">
<str name="clause">foo_field</str>
<bool name="clauseRequired">false</bool>
</shardKeyParserFactory>
{code}
That being said the implementation is going in a different direction that will
move the custom hashing configuration to be persisted within Zookeeper to allow
a client to be aware the custom hashing on the collection without having to
parse the solrconfig. I have not yet had the chance to review the work Yonik
has committed so far.
> Custom Hashing
> --------------
>
> Key: SOLR-2592
> URL: https://issues.apache.org/jira/browse/SOLR-2592
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Affects Versions: 4.0-ALPHA
> Reporter: Noble Paul
> Fix For: 4.1
>
> Attachments: dbq_fix.patch, pluggable_sharding.patch,
> pluggable_sharding_V2.patch, SOLR-2592.patch, SOLR-2592_progress.patch,
> SOLR-2592_query_try1.patch, SOLR-2592_r1373086.patch,
> SOLR-2592_r1384367.patch, SOLR-2592_rev_2.patch,
> SOLR_2592_solr_4_0_0_BETA_ShardPartitioner.patch
>
>
> If the data in a cloud can be partitioned on some criteria (say range, hash,
> attribute value etc) It will be easy to narrow down the search to a smaller
> subset of shards and in effect can achieve more efficient search.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]