[ 
https://issues.apache.org/jira/browse/SOLR-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455088#comment-13455088
 ] 

Michael Garski commented on SOLR-2592:
--------------------------------------

Thanks for the additional patch James.

It looks like the difference in approach between your patch and the one I've 
submitted is that rather than hashing on a value to determine the destination 
shard for an update, the shard name is added as a field on a document to 
explicitly name the destination shard. Is that accurate?

It is possible to combine our two approaches, however for explicitly naming the 
destination shard for an update perhaps adding optional properties to the 
AddUpdateCommand would be a better approach than to use a field in a document. 
The same could be done for a DeleteUpdateCommand to direct deletes to a 
specific shard(s) if desired. This would make index modification requests 
similar to a query where the names of the shards to be queried are present in 
the shards parameter as described on the wiki. The realtime get component would 
have to honor the shards parameter if present on a request as well, as without 
a way to determine shard membership from the unique id all requests to the 
realtime get component will have to be forwarded to all of the shards in the 
collection.

Thoughts, anyone?
                
> Pluggable shard lookup mechanism for SolrCloud
> ----------------------------------------------
>
>                 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
>            Assignee: Mark Miller
>         Attachments: dbq_fix.patch, pluggable_sharding.patch, 
> pluggable_sharding_V2.patch, SOLR-2592.patch, SOLR-2592_r1373086.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

Reply via email to