Thank you for this. I will be giving this a try, as I think it would
work well for us.
In the index, we'll store them as
Footwear>Outdoor>Mens>Fancy>Hiking>Boots>Waterproof, and upon getting
it out as a facet, we'll convert that into a <ul><li>footwear</li>..
list for display. Then we'll drill down using facet prefixes,
stripping the prefix from all the returned facets.
+--------------------------------------------------------+
| Matthew Runo
| Zappos Development
| [EMAIL PROTECTED]
| 702-943-7833
+--------------------------------------------------------+
On Jul 16, 2007, at 1:58 PM, Binkley, Peter wrote:
Here's one approach that should work: You could treat departments the
way the sample app treats manufacturers, with a manu field (tokenized)
and a manu_exact field (nontokenized). You would then do your initial
search (mens+footwear) on the dept field, and facet on the dept_exact
field, with facet.sort=false. This will give you an alphabetical
list of
relevant departments, which your application can group in whatever way
you need (show top-level departments with sub-departments in
javascript-activated dropdowns, whatever).
If a user clicks on a department or subdepartment to narrow their
search, you do a filter query on the dept_exact field, and use a
prefix
query to limit the facets in the result page if you want (e.g.
fq=dept_exact:Footwear>Mens*&facet.prefix=Footwear>Mens).
If you've got too many potential dept_exact values, I suppose you
could
bite off the top couple of levels into a dept_top_exact field and
facet
on that until the user drills down far enough that you need to go to
dept_exact. The dept field would contain the full department
string, so
they'd still find the dept_top_exact values that pertain to mens'
footwear even if the "Mens > Footwear" elements were deep in the
department hierarchy.
And of course populating these multiple fields can be handled
automatically in the schema using copyField elements.
Peter
Peter Binkley
Digital Initiatives Technology Librarian
Information Technology Services
4-30 Cameron Library
University of Alberta Libraries
Edmonton, Alberta
Canada T6G 2J8
Phone: (780) 492-3743
Fax: (780) 492-9243
e-mail: [EMAIL PROTECTED]
~ The code is willing, but the data is weak. ~
-----Original Message-----
From: Matthew Runo [mailto:[EMAIL PROTECTED]
Sent: Monday, July 16, 2007 1:26 PM
To: solr-user@lucene.apache.org
Subject: Re: Faceted Hierarchal Navigation
We were thinking of using SOLR simply because we'll end up navigating
around the products via facets at some level - so why not just use it
from the beginning.
For example, if we build the category landing pages from our DB, when
the user clicks on a link, they'll get dumped into SOLR to view the
products.. why not get the list of available categories to generate
the
landing page as well? Either way, we have to store the departments in
the index, right?
Am I trying to make SOLR do something it's not designed to do? Please
tell me if I am =p
+--------------------------------------------------------+
| Matthew Runo
| Zappos Development
| [EMAIL PROTECTED]
| 702-943-7833
+--------------------------------------------------------+
On Jul 16, 2007, at 12:13 PM, Corey Tisdale wrote:
So you want your category display to be controlled by SOLR? Why not
keep the hierarchical structure of categories in a RDBMS, then keep
the product index in SOLR?
Corey
On Jul 16, 2007, at 1:56 PM, Matthew Runo wrote:
Hello!
I was very surprised to find that this wasn't in the email archive
for this list.... I'm wondering about the best way to provide
hierarchal navigation using facets. For example, lets assume that I
have products with department trees like:
Footwear > Mens > Hiking > Waterproof (could be arbitrarily deep
though..)
Now, I need to make a "Mens Footwear" landing page. So ok, I'll
facet
on "department", for a search of "mens+footwear" present in
"department".
Oops.. now I'm showing lots and lots and lots of departments,
because
I don't know which ones are "higher level" than others.
Since each department has many departments under it, a full list
would be so long that people wouldn't use it. Information overload.
Ok, so I'll break up the "department" field, and put it into
"top_level_department" and "mid_level_department" and the rest of
the
items just in "department". The landing page will facet
"top_level_department", and upon rendering the page I'll query SOLR
to get all the "mid_level_department" facets for that
top_level_department. Then, if the user clicks on one of these,
we'll
facet on "department" to get the rest of them (and the
products) with the other two levels as filter queries.
That would work (right?), but it seems horribly wasteful to run all
those extra queries to get the sub-department facets. Surely
there is
a better way here.. just waiting to be brought to light.
How have you implemented hierarchal navigation via SOLR?
+--------------------------------------------------------+
| Matthew Runo
| Zappos Development
| [EMAIL PROTECTED]
| 702-943-7833
+--------------------------------------------------------+
