Results numFound (number of found items) in autocomplete differs from Results numFound in apachesolr_search_form serach results.
This happend when Apachesolr boost params are configured `/admin/settings/apachesolr/content-bias` cause apachesolr_autocomplete do not pay attention to these boost params.
Proposed Solution:
--- a/sites/all/modules/apachesolr_autocomplete/apachesolr_autocomplete.module
+++ b/sites/all/modules/apachesolr_autocomplete/apachesolr_autocomplete.module
@@ -228,7 +228,6 @@ function apachesolr_autocomplete_suggest($keys, $params, $theme_callback, $orig_
// Try to contact Solr.
try {
$solr = apachesolr_get_solr();
+ apachesolr_search_add_boost_params($params, $query, apachesolr_get_solr());
}
catch (Exception $e) {
watchdog('Apache Solr', $e->getMessage(), NULL, WATCHDOG_ERROR);
Comments
Comment #1
janusman commentedHeh, actully, this needs review.
Comment #2
janusman commentedHmm, on second thought...
The boost parameters never *change* the number of search results; they rather modify the ranking when using sorting by relevancy (the default sort). So this should not matter at all.
However, on that admin page, there's the "Exclude these content types from index" section... which doesn't affect search results, but rather indexing. So changing those merits reindexing (or indexing queued content with cron (or via batch API on the 6.x-2.x/7.x branches).
HOWEVER, do take a look at this issue, which might be what you're experiencing (if not the above): http://drupal.org/node/719382#comment-3458530
So, uhm, "works as designed" =)
Comment #3
janusman commentedI take it back. I see what's going on now; apachesolr_search_add_boost_params() adds the qf parameters to search, and if not caller we'll just be querying against the default search field noted inside schema.xml! Ok.
This will be fixed soon, part of another issue to bring the 7.x branch up to speed.
Comment #4
janusman commentedI take it back. I see what's going on now; apachesolr_search_add_boost_params() adds the qf parameters to search, and if not caller we'll just be querying against the default search field noted inside schema.xml! Ok.
Please see #1117792: Error in classes after updating latest apachesolr module version for patch to review.
Comment #5
itsekhmistro commentedLooks good, Thx.
Comment #6
janusman commentedThe above-mentioned issue is done, so it's fixed for 7.x, but I still need to check the 6.x branch.
Comment #7
janusman commentedFixed in 6.x branch.
Comment #8
Eaglecanada commentedJsut installed Apache Solr autocomplete 6.x-1.3. Still have the issue:
search "libraries", show 8 results in autocomplete, but apche solr search returns 80 results. The apache solr search seem include eveything from partial word to completed word: library, libraries, librarian, etc.
setting: types to exclude from the search index: panel.
any suggestions?
Comment #9
janusman commentedYes; there is no way around the fact that, whatever you search for, that query can be filtered (stemmed) so that you get more results back. AS_autocomplete can only count (for sure) actual (non-stemmed) words.
So, hmm... there is the option to:
a) retain the current (possibly wrong) counts in the autocomplete suggestions
b) switch off the counts entirely.
Perhaps ths show/don't show counts can be an admin setting, with the above proper warnings in the UI to give them the heads up (inside apachesolr_autocomplete_form_apachesolr_settings_alter())
Reopening... not sure if this still qualifies as a "bug" though =)
Thoughts?
Comment #10
Eaglecanada commentedlike the idea that putting "show/don't show counts" in the admin setting along with the warning, it will be very useful especially for the first time user using Apachsolr & this modules, like me. I have been spending an hour digging about this.
Comment #11
janusman commentedOk, here's an admin option! =)
Committing both of these patches to 6.x-1.x and master branches.