[prev in list] [next in list] [prev in thread] [next in thread]
List: solr-dev
Subject: =?US-ASCII?Q?Re=3A_=5BJENKINS=5D_Lucene-9=2Ex-Linux_=2864bit/hotsp?= =?US-ASCII?Q?ot/jdk-11=2E0=2E21
From: Uwe Schindler <uwe () thetaphi ! de>
Date: 2023-12-02 10:27:10
Message-ID: 08E63512-C8E9-46C2-BB8A-17CFFC4173F3 () thetaphi ! de
[Download RAW message or body]
Ha=2E Cool! Nice to meet=2E
I suggested to use this reader to some customers, but they were using Solr=
or Elasticsearch and it's not easy to implement it there=2E And they didn'=
t want to pay the expensive Uwe=2E =F0=9F=98=9C
How do you handle deletes=2E Because the main issue with those readers is =
that you can't update documents without also updating the main reader (alth=
ough it's a fake update)=2E
If this is used, have you thought of a SynchronizedMergePolicy that just a=
pplies the same merges in the secondary index?
Uwe
Am 2=2E Dezember 2023 10:27:20 MEZ schrieb Dawid Weiss <dawid=2Eweiss@gmai=
l=2Ecom>:
>> ParallelReader is also seldomly used, maybe we should remove support at
>> some point=2E I don't know anybody using it, because it is very complic=
ated
>> to maintain consistent indexes=2E It only works with stable merge polic=
ies=2E
>>
>
>You do know somebody - you know me=2E We're using it extensively - the
>scenario is for storing data derived from the main document in a separate
>index, merging this data dynamically=2E The data can then be reindexed/
>modified independently=2E Yes, we do use stable merge policies=2E
>
>Dawid
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www=2Ethetaphi=2Ede
[Attachment #3 (text/html)]
<html><head></head><body><div dir="auto">Ha. Cool! Nice to meet.<br><br>I suggested \
to use this reader to some customers, but they were using Solr or Elasticsearch and \
it's not easy to implement it there. And they didn't want to pay the expensive Uwe. \
😜<br><br>How do you handle deletes. Because the main issue with those readers is \
that you can't update documents without also updating the main reader (although it's \
a fake update).<br><br>If this is used, have you thought of a SynchronizedMergePolicy \
that just applies the same merges in the secondary \
index?<br><br>Uwe</div><br><br><div class="gmail_quote"><div dir="auto">Am 2. \
Dezember 2023 10:27:20 MEZ schrieb Dawid Weiss \
<dawid.weiss@gmail.com>:</div><blockquote class="gmail_quote" style="margin: \
0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> \
<div dir="ltr"><div class="gmail_quote"><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="auto">ParallelReader is also seldomly \
used, maybe we should remove support at some point. I don't know anybody using it, \
because it is very complicated to maintain consistent indexes. It only works with \
stable merge policies.<br></div></blockquote><div><br></div><div>You do know somebody \
- you know me. We're using it extensively - the scenario is for storing data derived \
from the main document in a separate index, merging this data dynamically. The data \
can then be reindexed/ modified independently. Yes, we do use stable merge \
policies.</div><div><br></div><div>Dawid </div></div></div> \
</blockquote></div><div dir="auto">--<br>Uwe Schindler<br>Achterdiek 19, 28357 \
Bremen<br><a href="https://www.thetaphi.de">https://www.thetaphi.de</a></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic