Thanks. I didn't know about the {!key=Location} trick.
Thanks everyone for your help. From what I could gather, there're 3 approaches:
1) SOLR-64
Pros:
- can have arbitrary levels of hierarchy without modifying schema
Cons:
- each combination of all the levels in the hierarchy will result in a separate
filter cache. This number could be huge, which would lead to poor performance
2) SOLR-792
Pros:
- each level of the hierarchy separately results in filter cache. Much smaller
number of filter cache. Better performance.
Cons:
- Only 2 levels are supported
3) Separate fields for each hierarchy levels
Pros:
- same as SOLR-792. Good performance
Cons:
- can only handle a fixed number of levels in the hierarchy. Adding any levels
beyond that requires schema modification
Does that sound right?
Option 3 is probably the best match for my use case. Is there any trick to make
it able to deal with arbitrary number of levels?
Thanks.
--- On Tue, 3/2/10, Geert-Jan Brits <gbr...@gmail.com> wrote:
From: Geert-Jan Brits <gbr...@gmail.com>
Subject: Re: Implementing hierarchical facet
To: solr-user@lucene.apache.org
Date: Tuesday, March 2, 2010, 8:02 PM
Using Solr 1.4: even less changes to the frontend:
&facet=on&facet.field={!key=Location}countryid
...
&facet=on&facet.field={!key=Location}cityid&fq=countryid:<somecountryid>
etc.
will consistently render the resulting facet under the name "Location" .
2010/3/3 Geert-Jan Brits <gbr...@gmail.com>
> If it's a requirement to let Solr handle the facet-hierarchy please
> disregard this post, but
> an alternative would be to have your App control when to ask for which
> 'facet-level' (e.g: country, state, city) in the hierarchy.
>
> as follows,
>
> each doc has 3 seperate fields (indexed=true, stored=false):
> - countryid
> - stateid
> - cityid
>
> facet on country:
> &facet=on&facet.field=countryid
>
> facet on state ( country selected. functionally you probably don't want to
> show states without the user having selected a country anyway)
> &facet=on&facet.field=countryid&fq=countryid:<somecountryid>
>
> facet on city (state selected, same functional analogy as above)
> &facet=on&facet.field=cityid&fq=stateid:<somestateid>
>
> or
>
> facet on city (countryselected, same functional analogy as above)
> &facet=on&facet.field=cityid&fq=countryid:<somecountryid>
>
> grab the resulting facat and drop it under "Location"
>
> pros:
> - reusing fq's (good performance, I've never used hierarchical facets, but
> would be surprised if it has a (major) speed increase to this method)
> - flexible (you get multiple hierarchies: country --> state --> city and
> country --> city)
>
> cons:
> - a little more application logic
>
> Hope that helps,
> Geert-Jan
>
>
>
>
>
> 2010/3/2 Andy <angelf...@yahoo.com>
>
> I read that a simple way to implement hierarchical facet is to concatenate
>> strings with a separator. Something like "level1>level2>level3" with ">" as
>> the separator.
>>
>> A problem with this approach is that the number of facet values will
>> greatly increase.
>>
>> For example I have a facet "Location" with the hierarchy
>> country>state>city. Using the above approach every single city will lead to
>> a separate facet value. With tens of thousands of cities in the world the
>> response from Solr will be huge. And then on the client side I'd have to
>> loop through all the facet values and combine those with the same country
>> into a single value.
>>
>> Ideally Solr would be "aware" of the hierarchy structure and send back
>> responses accordingly. So at level 1 Solr will send back facet values based
>> on country (100 or so values). Level 2 the facet values will be based on the
>> states within the selected country (a few dozen values). Next level will be
>> cities within that state. and so on.
>>
>> Is it possible to implement hierarchical facet this way using Solr?
>>
>>
>>
>>
>
>
>
