[
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741502#action_12741502
]
Hoss Man commented on SOLR-705:
-------------------------------
bq. 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.
I'm trying to look at it from an internal datastructure perspective, and a
client code perspective. From an internals perspective, keeping the data
isolcated makes sense -- one set comes straight from the Documents in the
index, the other is computed -- so they should be seperate datastructures
internally in solr, one hanging off the other.
Then the response writer can decide how it wants to deal with those data -- for
response writers where nested data structures are easy (most of them) this data
can be represented cleaning ... or we could add options to flatten the data
(using some prefix type option to say all metadata data properties should
become fields with the same name prefixed by "_") so that the client can't tell
the difference between them ... if we make the internal representation a
flattened list of pairs, then we tie the hands of hte response writter.
Ditto for the client library -- the more structure we maintain as the data
makes it's way to the client, the more options we have as to if/when we flatten
it. preserving structure allows code to flatten at anytime if it wants to, so
let's go with the option that has the most flexibility and get the best of both
worlds.
> 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.
