Apache Solr does not always filter down
poka_dan - March 13, 2009 - 13:39
| Project: | Apache Solr Search Integration |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | mkalkbrenner |
| Status: | closed |
Description
I use several vocabularies as facets and it appears apache solr module does not always filter down the categories.
What I mean is that (on occasion) it may choose to replace the existing filter instead of adding it.
Example :
Say I filtered down for tid:45 from vocab 1; when I hover on the individual(already filtered) facets of vocab 2 I sometimes get a link that causes the original filter to be replaced eg http://drupalydo/search/apachesolr_search/product?filters=tid:73 where tid is the new filter instead of what I would expect to have http://drupalydo/search/apachesolr_search/product?filters=tid:45 tid:73
Has anyone noticed that or am I doing something wrong?
#1
I ran into this bug too while I was working on this new feature: #401234: Reflect hierarchical taxonomy vocabulary in facet
The problem is located in Solr_Base_query.php. There is a static counter in method add_field which cause the issue if the query gets cloned.
Cloning a query object happens in facet blocks. So in this case you don't add but overwrite a field if you click on a facet link.
I attached a patch that fixes this issue.
#2
#3
I had occasionally seen this behavior, but hadn't had the time to investigate.
I'll help check this patch out, hopefully today.
#4
I don't really see why this is happening, but the patch looks reasonable.
#5
Tested the patch and it seems to have corrected the problem without introducing any new issues.
#6
heh, okay we know why Robert had the microtime() now.
I think his reason was something to do with the breadcrumb order? I really don't remember, but this is getting a bit ugly.
Otherwise, the patch looks reasonable to me, although I imagine there is some hidden problem here, I think we can commit it, it shouldn't be any worse.
Let's think also about ways to do this without cloning... Cloning is typically a source of memory leaks and ugly scoping issues like this.
#7
well, cloning is really the right solution - we need to start fresh each loop
#8
committed to 6.x - thanks.
#9
Automatically closed -- issue fixed for 2 weeks with no activity.