Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Subject: Re: Restricting/Filtering facet results
To: solr-user@lucene.apache.org
References: <56A0A0B5.9080505@uberresearch.com>
 <CALGoTy1Bm_K-8rmdskeqtZya5dAjTAbyDVfRi7xXTUVssbT=kA@mail.gmail.com>
From: Achim Domma <achim@uberresearch.com>
Message-ID: <56A0FC94.4030706@uberresearch.com>
Date: Thu, 21 Jan 2016 16:43:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
 <CALGoTy1Bm_K-8rmdskeqtZya5dAjTAbyDVfRi7xXTUVssbT=kA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

If I specify the query like this, I will get only one facet back. Or am
I wrong? I would have to specify one query for UserB and one for UserC.
My filter list can contain thousands of users, so specifying individual
queries is not an option.

On 21.01.2016 11:43, Binoy Dalal wrote:
> The facet.query parameter is what you're looking for.
> Use it like so:
> &facet.query=field:(UserB OR UserC)
> Check out the wiki for more details
> 
> On Thu, 21 Jan 2016, 14:41 Achim Domma <achim@uberresearch.com> wrote:
> 
>> Hi,
>>
>> is there some way to restrict/filter the facetting results? Our use case
>> is the following:
>>
>> Our documents have a multi value field, which holds user ids, so the
>> values might be like this:
>>
>> doc1 = ['UserA', 'UserB', 'UserC']
>> doc2 = ['UserA', 'UserB']
>> doc3 = ['UserA', 'UserC']
>>
>> Now I execute a search using a filter which restricting to documents
>> related to (UserB OR UserC). The result set will contain all three
>> documents, so the facetting result will be
>>
>> UserA: 3
>> UserB: 2
>> UserC: 2
>>
>> What I want to have is just:
>>
>> UserB: 2
>> UserC: 2
>>
>> Is there some existing solution for that? I'm currently thinking about
>> implementing a custom facet aggregation function, which only counts
>> values in my reference set (UserB, UserC). I checked the code and it
>> looks feasible, but I'm not (yet?) and expert of SOLR internals.
>>
>> Any hints, guidance, links to existing projects, patches, ... would be
>> very appreciated.
>>
>> cheers,
>> Achim
>>