Integrate API full text search into the ApacheSolr setup
webchick - September 14, 2006 - 20:39
| Project: | API |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | drupal.org redesign |
Description
You can currently search for function name, which is helpful if you know what you're looking for, or if you know what one word in a function is, but doesn't help you at all for finding things like form API properties referenced in documents like http://api.drupal.org/api/4.7/file/developer/topics/forms_api_reference....
Not sure what the answer here is; if each file should be imported as a node? But I just came across a very frustrated developer who missed the Form API reference entirely because of this.
#1
Yes, I have seen this be a problem before. API should support full-text searching with search.module.
#2
Yes, full-text searching in search.module will really improve the learning time of the developers. This makes their learning more easy.
#3
Integrated search with api.drupal.org is called for in the MBD redesign. We will be using Apache Solr for searching Drupal.org.
#4
Subscribe. I will help write a module that integrates with Solr for this.
#5
#6
#7
Here.
#8
Here is how it looks like:
#9
Just took a quick look - "pseudo-node"?
#10
Comments really like having nids, so we have well-hidden nodes.
#11
One thing we will have to do is to store the object_name in a tokenized form, in addition to the string form. Right now, neither "node_load", "node load" nor "load node" match "node_load_multiple".
#12
@Damien - I'm surprised those don't match - what tokenizer are you using? Or you mean it's not tokenized at all - so it should be in a text field instead?
#13
@pwolanin, not it's a string field right now. I think it make sense to keep both a text field and a string field, and to boost the string field to the maximum to boost exact matches. What do you think?