Yeah~, writing to true data store first, then write to solr. I found it is
simple to guarantee the finally consistency,
only handling two main exception bellow:
1. If failed to write to true data store，then client samply retry its
request。
2. If write true data store success，and failed to write to solr， it will
retry to solr infinitely。
If write to solr is failed，and server was kill，I can use the
transaction log of the true data store to replay and write to solr again。
Shawn Heisey <apa...@elyograg.org> 于2018年9月19日周三 下午10:38写道：
> On 9/18/2018 8:11 PM, zhenyuan wei wrote:
> > Hi all,
> > add solr document with overwrite=false will keepping multi version
> > documents，
> > My question is ：
> > 1. How to search newest documents？with what options？
> > 2. How to delete old version < newest version documents?
>
> When Solr is compiling results, it will only return one copy of a
> particular document (based on uniqueKey value).All other copies will be
> removed.
>
> I suspect (but do not know for sure) that which document will be
> returned is not defined. On a multi-shard index, if different copies
> are in different shards, which one is returned will be decided by which
> shard answers the query first, or maybe which one answers last. If
> multiple copies exist in the same core, that's probably more
> deterministic, but it might not be the copy you wanted.
>
> Solr isn't designed to have multiple versions of the same uniqueKey in
> the index. Lucene itself doesn't care -- it's going to return all of
> them -- but if you want to be sure which one is returned, you'd need to
> write the Lucene-based software yourself instead of using Solr.
>
> As you mentioned in the last message, writing to your true data store
> and then writing to Solr if that succeeds is a better option. Or you
> could simply write to your data store and then have your indexing
> software detect and read the new records from there.
>
> Thanks,
> Shawn
>
>
