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