On 5/12/06, Fabio Confalonieri <[EMAIL PROTECTED]> wrote:
I tried a query like "+field:value^0" which returns a great number of Hits
(on a total test of 100.000 documents), but I see only the query cache
growing and the filter cache always empty. Is this normal ? I've tried to
check all the cache configuration but I don't understand if filters are
auto-generated from normal queries.
There is currently no syntax in the standard request handler that
understands filters.
Converting certain "heavy" term queries to filters when they have a
zero boost was something Doug pointed me at and I borrowed directly
from Nutch very early on, before Solr had it's own caching.
The optimization code is still sort-of in Solr, but
- it's not called by default anymore... people needing faceted
browsing currently need their own plugin anyway, and they can then
specify filters directly.
- it's caching is not integrated into Solr's caching
Filters *can* be generated and used to satisfy whole queries when the
following optimization is turned on in solrconfig.xml:
<!-- An optimization that attempts to use a filter to satisfy a search.
If the requested sort does not include score, then the filterCache
will be checked for a filter matching the query. If found, the filter
will be used as the source of document ids, and then the sort will be
applied to that. -->
<useFilterForSortedQuery>true</useFilterForSortedQuery>
A more general question: Is all the CNet logic of intersecting bitsets
available through the servlet or have I to write some java code to be
plugged in Solr?
The nitty-gritty if getting intersection counts is in Solr, but you
still need to ask solr for each facet count individually, and you
still need to know which counts to ask for. Thats the part you
currently still need a custom request handler for.
In this case which is the correct level to make this, perhaps a new
RequestHandler understanding some new query syntax to exploit filters.
Yes, a new RequestHandler.. from there the easiest way is to pass
extra parameters (not changing the query syntax passed as "q").
We only need a sort on a single and precalculated rank field stored as a
range field, so we don't need relevance and consequently don't nedd scores
(which is a prerequisite for using BitSets, if I understand well).
You can do relevancy scoring *and* do facets at the same time... there
is no incompatibility there.
-Yonik
