magibney edited a comment on pull request #624:
URL: https://github.com/apache/solr/pull/624#issuecomment-1045310607
Well "`fq=filter(foo:bar) OR foo:baz`" is already supported, and this PR
wouldn't change that particular example; and yes this example illustrates one
reasonable use of `filter(...)`: to separately consult the filterCache for the
"`foo:bar`" subclause, in addition to consulting filterCache (in this example)
for the overall `fq`.
So appropriately, this example would result in two filterCache
consultations. This PR addresses the case where `fq` and `filter(...)` are
coterminous -- where they represent exactly the same fundamental query, but
would currently be cached twice.
I guess the way I think about it, `filter(...)` gives you arbitrarily
granular control over how subclauses get cached. The `fq=filter(...)` example
is really straightforward, but is admittedly unlikely to come up in "real
world" use. The use that initially motivated my interest in this is perhaps
informative: the `relatedness` JSON facet function accepts a single query arg
to define its "foreground set". For obvious reasons, I wanted to define the
foreground set to be "the combination of main query and filters", but I found
that doing so via the FiltersQParser ("`{!filters param=$q param=$fq}`")
resulted in consulting the filterCache for the top-level combination of q&fq,
not finding it (of course), and running all the underlying queries without
consulting the cache! Having fixed FiltersQParser to generate FilterQuery
instances for its individual subclauses (separate PR forthcoming), I found that
each of the subclauses was getting cached twice: once as the clause's
underlying quer
y, and once as the clause's FIlterQuery wrapper. That behavior is what this PR
fixes, and the behavior that the associated test is designed to evaluate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
