[
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-705:
-------------------------------
Attachment: SOLR-705.patch
Here is an updated patch that:
1. Calculates the Set of returned fields once per requres (rather then for
each document)
1. Attaches the meta return field list to the SolrQueryResponse
1. implements a ReturnFieldList that will match "*" to return any meta field
(NOTE, we should consider
http://wiki.apache.org/solr/FieldAliasesAndGlobsInParams)
-----
I like that this gives us an extendible place to augment each document without
having to map the ID.
I don't like the potential name conflict using "meta" (or any string) in the
field list. Since you have to explicitly turn on the query, i guess it is ok;
BUT it makes things difficult for parsers. Is the "meta" field the special key
or a field?
Since solr does not support NamedList as a field, we could asume that any <lst
is the special meta field, but that seems kinda ugly.
> 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.
