[
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740984#action_12740984
]
Yonik Seeley commented on SOLR-705:
-----------------------------------
I go back and forth on the "meta" thing...
On one hand, if one is looking at the output, it makes perfect sense to have a
separate meta section per document.
However, when one looks at it from a client API perspective (how one asks for
the value of a particular metadata value) having two different ways to access
values ("real" fields vs "meta" fields) doesn't seem desirable.
>From a client coding perspective, consistency is nice:
sdoc.get("id")
sdoc.get("_shard")
After all, many of the stored fields of a document are actually just metadata
too. So an alternative is simple convention... metadata fields start with an
underscore, and no more work needs ot be done at the client side.
But I'm really not convinced either way ;-)
> 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
> Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch,
> SOLR-705.patch, SOLR-705.patch, 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.
