Otis Gospodnetic wrote:
Yes, that's the standard trick. :)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
----- Original Message ----
From: gwk <g...@eyefi.nl>
To: solr-user@lucene.apache.org
Sent: Wednesday, February 25, 2009 5:18:47 AM
Subject: Re: Distributed Search
Koji Sekiguchi wrote:
gwk wrote:
Hello,
The wiki states 'When duplicate doc IDs are received, Solr chooses the first
doc and discards subsequent ones', I was wondering whether "the first doc" is
the doc of the shard which responds first or the doc in the first shard in the
shards GET parameter?
Regards,
gwk
It is the doc of the shard which responds first, if my memory is correct...
Koji
Ok, so it wouldn't be possible to have a smaller, faster authoritative shard for
near-real-time updates while keeping the entire dataset in a second shard which
is updates less frequently?
Regards,
gwk
Ok, now I'm confused, if the shard the document comes from is
non-deterministic, how can you use this 'trick'? (except that since the
response time of the first shard which is smaller is usually better
which would mean it'll work most of time (BAD!)) Or was Koji's memory
incorrect and the shard first mentioned is always the authoritative
shard when encountering duplicate keys?
Regards,
gwk