lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: ToParentBlockJoinQuery vs filtered search
Date Mon, 06 Feb 2012 13:54:18 GMT
On Sun, Feb 5, 2012 at 11:43 PM, Mikhail Khludnev
<> wrote:

> Thanks for resolving my hesitations. It allows me move forward.

You're welcome!

>> It looks like that's what your test case is testing for...?  Does it pass?
> Of course it doesn't.
> the first reason is that BlockJoinWeight.scorer()
> has the opposite intention (btw, are you %100 sure?):
>  * Children query is filtered by the given filter
> childWeight.scorer(readerContext, true, false, *acceptDocs*);
>  * Parent filter  is not constrained
> parentsFilter.getDocIdSet(readerContext,
> *readerContext.reader().getLiveDocs()*);
> That's why I asked for the rationale of filtered BJQ search.
> The also complication which I met is that
> AssertingIndexSearcher.wrapFilter() randomly switches from filtered
> search to FilteredQuery.
> it leads to IllegalStateException"parentFilter must return
> FixedBitSet; got "BitsFilteredDocIdSet. I suppose I can deal with it.

Hang on -- there are 2 different filters here.

The first one, the parentsFilter that you pass to
ToParent/ChildBlockJoinQuery, is very specific: it must identify which
docs are parent docs.  This is unchangeable: every BJQ must use this
same filter, since what is parent and what is child was determined at
indexing time when you indexed the blocks.  It must produce a
FixedBitSet per segment (using CachingWrapperFilter does so).

The second filter, is the optional filter the outside app can pass to -- it's this filter that I was describing in my
last response (ie, that it will be used in the "to" document space,
only).  This filter is obviously free to change per query, depending
on what the app is doing...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message