lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (SOLR-705) Distributed search should optionally return docID->shard map
Date Thu, 30 Jul 2009 06:28:14 GMT


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


|{{?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:
>             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.

View raw message