I was thinking more that it would be an extra field you get back. My understanding of doing updates requires:
1. get your document (either by ID or from a search) 2. merge your update into the doc 3. update solr with the doc (which essentially just writes it all again but as you have done the merge nothing is lost). for shards, i would read from the main shard but write directly back to the shard directly. The idea is that you don't need to concern the main server with an update to a child shard (unless this direct bypass is dangerous somehow). So finding out which shard it came from on the initial "get" is key to know where to send the merged document. Some sort of "computed field" would work here. Something that is not actually in the index but is returned. The indexing and storing of the value is not needed as you can always filter which shards you want when creating the query. On Tue, Aug 19, 2008 at 8:59 AM, Brian Whitman <[EMAIL PROTECTED]> wrote: > > On Aug 19, 2008, at 8:49 AM, Ian Connor wrote: > >> What is the current "special requestHandler" that you can set currently? > > If you're referring to my issue post, that's just something we have > internally (not in trunk solr) that we use instead of /update -- it just > inserts a <field name="shard">hostname:port/solr</field> into the incoming > XML doc add stream. Not very clean but it works. Use lars's patch. > > > > -- Regards, Ian Connor 1 Leighton St #605 Cambridge, MA 02141 Direct Line: +1 (978) 6333372 Call Center Phone: +1 (714) 239 3875 (24 hrs) Mobile Phone: +1 (312) 218 3209 Fax: +1(770) 818 5697 Suisse Phone: +41 (0) 22 548 1664 Skype: ian.connor
