Posted by DamienMcKenna on June 23, 2009 at 3:39am
| Project: | Apache Solr Search Integration |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Solr provides a complete replacement for the built-in search engine, so why retain a dependency on the core search.module? Right now, if I'm reading this correctly, if you want to only use the Solr search engine and not waste the database & system with unwanted search.module calls you have to run a basically hack core to remove certain lines out of search.module (using CoreSearch.module)? Obviously, this is a bad situation, advocating hacking core is not a good thing. Why not just duplicate the functionality that's needed out of search.module and drop it completely, leaving a much cleaner system?
Comments
#1
http://drupal.org/node/405206
#2
Thanks. I searched but didn't include "fixed" in the criteria so didn't find this one. Glad to see it.
#3
We need to go ahead with the original intent of this issue and completely decouple our module from core search. Core search enforces way too many assumptions and limitations. For example, we call search_data() for no good reason... all it does is invoke our apachesolr_search_search hook. Then, we use the standard theming for core search results. This breaks if you want to display more or less than 10 results per page because the THEME layer assumes 10 items (core search has this assumption hardcoded in many places):
<?phpfunction template_preprocess_search_results(&$variables) {
$variables['search_results'] = '';
foreach ($variables['results'] as $result) {
$variables['search_results'] .= theme('search_result', $result, $variables['type']);
}
$variables['pager'] = theme('pager', NULL, 10, 0); // <---- eat that, sucka!
// Provide alternate search results template.
$variables['template_files'][] = 'search-results-'. $variables['type'];
}
?>
So I'm reopening the issue with the original title and original intent.
#4
Here's step one. Instead of calling search_data, call apachesolr_search_search directly. Eventually I'd like to refactor apachesolr_search_search to be individual functions and not related to search module's API.
#5
subscribe. still a big fan of this direction.
#6
And another baby step. Don't depend on search.module to call cron for us.
#7
Committing these two patches. More to come.
#8
Ok. These are truly baby steps. That last patch broke things so I have to pull in some of the code from search_data to compensate. One layer of extrication at a time :(
#9
How about a patch that clears the core search_* tables on cron?
#10
Damien, what would such clearing accomplish? Just "truncate search_index" and so forth? And, why would we need to do that every cron run?
Controlling core search behavior isn't really the purview of the ApacheSolr module, imo.
#11
Subscribe. search.module's cron is never happy, and I have to manually trigger it (using Elysia cron) in order to get the apache index to be updated. I vote to get rid of search.module when using Solr.
#12
I think my issue is a duplicate. #719902: Less branding please
I hope part of the direction here is to remove the apache solr branding from search, and just use 'search'.
#13
you can change urls with aliases or with hook_menu_alter(). anyway, changing urls is not a goal of this issue. feel free to keep the other one open.
#14
In the mean time, is there a way (besides hacking search.module) that I can simply have search_cron *not* do its indexing process and build a huge database table (which is the primary cause of my site's inability to run cron)?
#15
@gerlingguy - no, you have to hack core. Either use the coresearches patches, or just go in and add return FALSE; to the indexing functions.
#16
@robertDouglass - okay. Hopefully this issue picks up a little steam soon, then. I hate killing kittens!
#17
Doesnt http://drupal.org/node/405206 which has been commited already have a fix so core search doesnt index anything? I have my core search index setting set to zero.
#18
subscribing. we've got several hundred megs of search indexes that we'd love to stop moving around in database backups.
#19
The three patches here are committed. Let's open a new issue for remaining tasks.
@drewish - to prevent search.module from indexing you can set the number core search is to index per cron run to 0.
#20
Automatically closed -- issue fixed for 2 weeks with no activity.