Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <932158219.1249769714941.JavaMail.jira@brutus>
Date: Sat, 8 Aug 2009 15:15:14 -0700 (PDT)
From: "Yonik Seeley (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=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.