Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <1170937698.1248935294840.JavaMail.jira@brutus>
Date: Wed, 29 Jul 2009 23:28:14 -0700 (PDT)
From: "Hoss Man (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Commented: (SOLR-705) Distributed search should optionally
 return docID->shard map
In-Reply-To: <1934249606.1218820184259.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.