ok. It takes a while to scratch some code with a test
https://issues.apache.org/jira/browse/SOLR-16242
https://github.com/apache/solr/pull/623 Please chime it!
On Tue, Feb 15, 2022 at 11:01 AM Mikhail Khludnev wrote:
> It turned out to be a little bit more optimistic after I moved the cache
> ch
It turned out to be a little bit more optimistic after I moved the cache
check into QueryWrapper.createWeight(Searcher, ...,... ). TBC.
Joel,
Regarding moving inventory into the main index, I'm afraid it requires
frequent commits into the main index and impacts search latency.
On Mon, Feb 14, 202
Hi, David and Joel.
It took a while. I kicked tires a little
https://github.com/apache/solr/pull/623
I introduced {!join cacheEventually=true} param. It yields false positive
JoinQueries (ignores fromCore timestamp), and backed on docsets reside in
the user cache.
Cache listener doesn't suit for th
The second approach (newSearcher listener) is a nice approach if the filter
cache is too full to rely on auto-warming.
Static warming queries fail on cross core joins but I believe succeed on a
self core join. So you could move the inventory into the same core and use
a static warming query. The do
I'm not sure there is a clean/simple solution to this specific problem.
But I could imagine a more general & simple feature that could solve this
scenario, with just a bit more work by the user.
Imagine an optional cache-key on ExtendedQuery auto-parsed, perhaps with
local-param "cacheKey". It wo
Hello, Colleagues.
I want to discuss one frequent usecase: inventory updates.
Let's say we can't reindex docs when inventory numbers updated. We can put
inventory in separate index, and apply fq={!join ..
fromIndex=inventory}left:(0 TO *]. Once it's cached in main index filter
cache it gets a good
