If your Django application needs searching capabilities, you can roll your own. Or you can use my generic search view. This provides a parser for queries and a search machinery that is suiteable for moderate database sizes. It provides an extensible google-like syntax.
The main problem is that django doesn't support OR query combinations and that it doesn't support "icontainsnot" queries. So the search engine does multiple selects to get one query. It starts with the longest search word and goes down in size from that result set, restricting it from one step to the next. But since it needs to keep the last result set in memory (at least the list of IDs), if your database contains too much rows, this might pose problems to your server (especially if the users do silly queries that produce large resultsets).
Maybe in future this will learn some optimizations to make it work better with larger databases, but it's quite fine as a search engine for your blog or standard content management systems.
Adrian Holovaty Oct. 25, 2005, 4:19 a.m.
Oh, did you want Django to have "icontainsnot" support? That'd be super-easy to add...
hugo Oct. 25, 2005, 10:47 a.m.
Yes, it would make some things easier, if there was an icontainsnot. Ok, not too much easier, because another limitation can't be easily lifted: django uses keyword args to define query parts, but a keyword can only be used once in a call. So I can't do several icontains or icontainsnot to the same field (as I might have multiple search words or search not-words).
It looks like I should maybe do some WHERE clause generation on my own and just use the operator mappings from the database driver, instead. The current incarnation of the search just produces too much SQL queries.