search

So I have been tasked with solving the issue of stemming, mispellings, multilingual and partial matching for a site. I decided to create a quick prototype for n-gram indexing. (http://en.wikipedia.org/wiki/N-gram among other resources) . It is a relatively proven technique for these issues, but creates a larger index. So of course not sure if it is the best route in terms of performance, but I plan on running tests.

Last night we enabled Pivots recommendations on Drupal.org. We've been working on Pivots for almost 18 months and I think it represents an exciting new type of Drupal.org service. Today pivots uses a custom indexer written in Java. That indexer reads the content on Drupal.org and then indexes it to the masterdb-other.drupal.org a database server outside our main Drupal.org database servers.

See: http://mrzhou.cms.si.umich.edu/diagram-pivots-recommendation-system-do

I would like a custom search form with search "input form" to query a certain vocbulary.

I have looked at views, fastsearch, filter block

They are ok to use when you want a drop down, not a "text input". I have about 450 terms, from a vocabulary I want to be queried.

I believe a drop down would not be user friendly, also it would load as fast.

On my site, a directyory listing, the search form would be of this nature

|keyword| |location| |business type| Search Button

I've created a test case that tests the advanced search form. There are currently no other tests that do this. The patch needs review. Please jump in and give it some attention: http://drupal.org/node/308233

I thought you guys might be interested in these search numbers from DrupalModules.com. It turns out they're very similar to what's being reported by Drupal.org. One thing to note, my data has been filtered for IP-uniqueness to prevent result spamming (intentional, or not), the Drupal.org data is just coming right out of the watchdog log unfiltered.

Hey everyone. I just finished up work on my Summer of Code project that was targetted at further developing the core search. During the course of the project I created a module for Drupal 6 that back ports DougGreen's hook_ranking() patch that made it into HEAD. The module uses hook_menu_alter() and some other work to override the core search implementation completely. This module also includes some other cool new things listed below. I'd like to get some feedback on the changes that have been made because I want to create some patches for the new features to be integrated into HEAD.

(repost from http://drupal.org/node/296198 by drunkenmoney)

While implementing the attachment indexing mechanism, we (febbraro, robertDouglass and I) stumbled across a problem: how to store the attachment text?
It would be easily possible to just append it to the "text" field or add a new, multi-valued field or both. But then it would be impossible to distinguish the place of occurence of the term at search time, which, unfortunately, is a requirement, since the attachments should appear directly in the search results, not just links to the nodes containing them.

I have a few Drupal sites running from one code base and one database. The tables currently shared are Authmap, profile_fields, profile_values, role, sessions, users and users_roles.

I want the search to search all of the sites, can this be done by just sharing the search tables or is it more complex.

Tim

I've posted a first cut at a patch to refactor core search into a generic search module that accepts different backend handlers and a specific handler, core's custom indexing. It's a very basic patch--it just does the minimum to decouple the generic search interface from the backend.

The aim is to permit e.g. apachesolr and other search backends to plug in seamlessly to core search.

Ready for review: http://drupal.org/node/282192.

Need some clarifications on the best search algorithms to use. I work with a Netlink Technologies. We are currently planning to have a Architect a large Job portal in Drupal. Have convinced our organization that we use Drupal 6.0 and create custom nodes and modules. We are also planning on bench marking the different options of Search that we could adopt.

For Search we are just trying to understand ApacheSolr and Sphinx search.

DO you think we are proceeding in the right direction. Will Drupal - SOLR be a scalable option for a large job portal?

Shyamala
Tech Head