is this good for "search"

[mixmix]

I recently needed to make a "search by name" feature for the new sorts of profile I've made. Basically I need to search across several fields for some sort of partial match.

Example:
search : "ben"
should find:

• records with preferredName like "james ben", or "Benjamin"
• records with legalName like "Big Ben"
• records with altNames like ["bj", "benny"]

I've implemented something simple with flumeview-search which I'm pretty happy with but also interested in trying this out.

Obvious challenges for a module like this :

• case insensitivity
• finding partial matches (e.g. a regexp /ben/)

This may be totally the wrong tool, but thought I'd put this test case at your doorstep in case it's of interest / use

[mixmix]

Another thing I'm worried about for my use case is that I'm gonna be doing live search as people type. My understanding of this module is that it would create different indexes for individual searches ben and benj and benja etc.

[dominictarr]

Ah, I didn't really intend this for that sort of thing. as it currently is, the main reason it wouldn't work is that it uses a hash table and so you can't do partial matches... so if you typed "foo" it _couldn't match "food". maybe there are some ways you could work around this though.

you wouldn't want to rebuild indexes for each search because you probably don't do the same search again very often. building an index takes ~ 8 seconds, with a warm cache, which is okay if you are using an app that only has delay the first time. The way it works is if you do a query like root=<id> it builds indexes for every value of root, so any other query with root in it is now fast. Some times it might create indexes you don't need, say you query type=post it indexes every type, but you only ever query for posts. anyway, seemed like a reasonable trade off.