Don't move fq params to q.alt if fq params include local params
jpmckinney - December 1, 2009 - 18:14
| Project: | Apache Solr Search Integration |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
In an apachesolr_modify_query hook, I set local params ex and tag for various purposes. Note that I'm not using these local params to do OR faceting, so the special case in the 6.x-2.x branch - if (!$has_or ...) { - is no use.
A more general solution would be preferred. Here's something that would fix the bug for my case and the 6.x-2.x $has_or case, in all versions of apachesolr.
| Attachment | Size |
|---|---|
| patch.patch | 933 bytes |
#1
Looks like a bug indeed, but note from php.net re: strstr():
Also, should we consider just moving one or more fqs if possible for the performance reasons even if we cannot move all?
In other words we should possibly test each fq, not the imploded list of them?
#2
Re-rolled to test each fq.
It also omits filter queries starting with '-', as these don't seem to work in q.alt. I discovered this when doing a key-less search with a -language:fr filter using apachesolr 6.x-2.x.
#3
This last patch is against 6.x-2.x, but a patch that excludes the $has_or changes will work against 6.x-1.x.
#4
should probably check
if ($move_fq) {before this line:
$params['q.alt'] = implode(' ', $move_fq);#5
Amended.