[
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737012#action_12737012
]
Hoss Man commented on SOLR-705:
-------------------------------
i haven't looked at any of the patches here, but the simplest way to avoid
field name collision problems would be to make the client specify the name of
the "meta" field when asking for it
examples...
|{{?q=solr&meta=myMetaFieldData}}|empty NamedList named 'myMetaFieldData' in
each doc|
|{{?q=solr&meta=foo&shardMapping=true}}|NamedList named 'foo' in each doc, each
containing a single "shard" key/val|
|{{?q=solr&shardMapping=true}}|shard mapping data is computed, but response
writer has no instructions on how to display it; behavior can be implementation
dependent (xml might be implemented as a <lst> with no name, binary might
decide to leave it out completely)|
> 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-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.
