Allow Apache Solr to be the default, let search module index 0 nodes per cron run
moshe weitzman - March 17, 2009 - 19:41
| Project: | Apache Solr Search Integration |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
IMO, the dependency on search module gets in the way. For one, search.module always indexes nodes and can't disabled without hacking.
I know about coresearches module which is a nice way of saying - hack core. Core search is not worth hacking - I prefer it disabled.
#1
I think we have an issue for this already, but I don't see it.
@pwolanin: Do you know where it is?
And yes, I agree to the above points BUT it would be nice to have a *better* search framework so that users can seamlessly switch between Solr and Sphinx or back to core search without theming, etc issues.
So seeing as we don't have a better one, I'm a little reticent to move off of core search. I'm actually fine with it, but I think we should make sure we maintain compatibility.
#2
hmm, I can't find it either.
#3
Issues for Core searches
http://drupal.org/project/issues/coresearches
#4
@coupet - no, this would be an issue for just this module.
#5
It would be great if we could come up with the different scenarios for/against dependancy on core search. here's a possible starting list:
Cases when removal of core search dependancy is good:
* Don't need core search, and will no longer have core search indexing what is already on the Solr index.
* ??
Cases when it's bad:
* D7 or later gets the Search API it deserves, and Apache Solr module would have to "go back" and integrate with that.
* Would have to duplicate functionality offered in other modules (like OpenSearch which can now provide RSS for Apache Solr results).
* ??
#6
Would it be too far-fetched to support two interfaces, one that would stand by itself, and another based on hook_search(), by refactoring some stuff into separate modules?
#7
@David - that was basically my intention, since the amount of code specific to hook search is actually minimal.
#8
With #469642: Pull facet blocks out of apachesolr_search.module, we could have a small step done to take some code out of apachesolr_search.module, to favor its re-use by other modules such as a potential search module that would not be dependent on core search.
#9
Looking at this now - a little trickier than I initially thought since we use user_access('search content') and there is various block and theme code.
#10
WIP, non-functional.
#11
Thinking about htis more - it would be easier to just form_alter to allow 0 nodes indexed by core node search (thanks Jody).
#12
new title, patch.
#13
It seems to work properly for me. :)
#14
Committed...
Accidentally let CVS but the wrong comment in with -m on the command line once, but got it in proper.
#15
Thank you for this, I was really confused why core Search needed to be used given the entire engine was being replaced. I will give the next beta a good solid thrashing on a 70k+ node site.
#16
Automatically closed -- issue fixed for 2 weeks with no activity.
#17
Thanks for this. I had to make a special accomodation for this clever hack in the search index command in drush. Search for Apachesolr at http://cvs.drupal.org/viewvc/drupal/contributions/modules/drush/commands...