lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrien Grand <>
Subject Re: LRUQueryCache appears to be messing with me
Date Thu, 10 Mar 2016 07:08:42 GMT
I think the best option would be to change your query objects so that they
are not equal when they may return different results as you suggested in
item 4.

Le jeu. 3 mars 2016 à 07:22, Trejkaz <> a écrit :

> Hi all.
> I spent a while trying to track down some weird behaviour where our
> custom queries that work off information outside Lucene were returning
> out of date information.
> It looks like what's happening is that LRUQueryCache compares the
> queries, decides that they're the same (equals() does return true) and
> returns out of date info.
> Is there a recommended way to deal with this? I can think of a few
> possibilities.
>   * Stub out the caching with a null implementation of QueryCache.
> (Current preference. Would slow things down but practically none of
> our "filters" are of the type which this thing could correctly cache
> without changes.)
>   * Try to implement our own QueryCachingPolicy which looks at the
> Query object and somehow figures out whether a given query is still
> valid. (Probably makes more sense, but doesn't fit very well with our
> current model where we programmatically invalidate queries.)
>   * Try to implement QueryCache directly on our existing query cache
> class. (Seems to make sense too, but difficult because ours takes
> Query and Lucene's takes Weight.)
>   * Try to change the Query objects such that two queries created from
> the same query text end up not being equal(). For instance, keep track
> of the last change anyone makes to a database and pull that every time
> a query is parsed. Queries with the same time will share data and ones
> created after a change occurred would not use the cached data.
> Alternatively, maybe there is a supported way to do filters against
> external stores by now? It has been quite some time since the last
> time someone said "don't do that", so I thought I'd check that too.
> TX
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message