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

Lars Kotthoff commented on SOLR-705:
------------------------------------

bq. I don't think we need to worry about returning an array of all shards... 
they are supposed to be disjoint

I think as the idea behind the issue is to use this information to 
programmatically update/delete documents, we should return an array of shards. 
Consider the scenario where 2 sets of shards index the same information for 
redundancy purposes. For normal queries, you would send requests to one set of 
shards. If you want to delete a document, it would be nice to be able to send 
one request to both sets of shards and get all the required information with a 
single request instead of having to query each set individually.

bq. What about putting the docid->shard mapping elsewhere in the response 
rather than actually on the document?

That assumes that there's a unique key which we can use to link the two pieces 
of information. That's probably a reasonable assumption, but in my opinion we 
shouldn't impose this restriction unless it's really necessary.

bq. I've also thought about a "meta" part to a document that contains other 
information specific to the document besides stored fields.

Ah, I do like that idea.

bq. Well, can you filter/query/sort by the contents of this "shard" field? If 
not, it doesn't belong in the doc block, IMO

It's the same thing for the score field though.

> Distributed search should optionally return docID->shard map
> ------------------------------------------------------------
>
>                 Key: SOLR-705
>                 URL: https://issues.apache.org/jira/browse/SOLR-705
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 1.3
>         Environment: all
>            Reporter: Brian Whitman
>             Fix For: 1.4
>
>         Attachments: SOLR-705.patch
>
>
> SOLR-303 queries with &shards parameters set need to return the dociD->shard 
> mapping in the response. Without it, updating/deleting documents when the # 
> of shards is variable is hard. We currently set this with a special 
> requestHandler that filters /update and inserts the shard as a field in the 
> index but it would be better if the shard location came back in the query 
> response outside of the index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to