Towards a django.contrib.site_search (Part 2)

Search engine indexing is the foundation of search. Although some RDBMS—notably Postgres—allow you to build ad-hoc full text search indices from an arbitrary number of table columns at query time, the best approach both for universality across DB back-ends and for performance is to build an index of relevant content that exists alongside and is updated with that content; in other words: a cache-based search engine. Given that we’re using the capabilities of the supported Django RDBMS to query these indices, it makes sense to store these them in a database table. But where, exactly?

Somewhat ambitious, I know, but I’ve become convinced that site search is the next frontier for Django. Let’s face it: users like search. Everyone knows how to use it. It’s usually the first thing people with the goal of information-finding turn to. Before site maps, before content hierarchies, before tags...people turn to search. That’s a good thing, if you have a search for them to use and itt works well.

Over the next two weeks, I hope to outline an approach to building a site search application that will work well, scale well, be as easy as possible for application builders to implement, and accord with the design goals of Django. And if I’m lucky, perhaps some form of this will make it into django.contrib. There’s certainly no surfeit of requests for such a feature. 

Before we begin, a warning: although I have the architectural approach pretty well laid out in my head, I’m still writing the code. These posts will not lack for code snippets (well, this one will), but I probably won’t be ready to provide the full version of the app until the final post. So, caveat lector—these posts demonstrate a work in progress. That said, if I later reverse course on something I outline in a post, I promise to note that in the next one.