I recently switched a Django project utilizing Haystack from Whoosh as the engine to Xapian. The performance significantly improved, but I was left with some deficiencies in the search results — this turned out to be due to the default settings.

Here are the necessary settings to improve the search result quality:

import xapian

HAYSTACK_XAPIAN_FLAGS = (
    xapian.QueryParser.FLAG_PHRASE |
    xapian.QueryParser.FLAG_BOOLEAN |
    xapian.QueryParser.FLAG_LOVEHATE |
    xapian.QueryParser.FLAG_WILDCARD |
    xapian.QueryParser.FLAG_PURE_NOT |
    xapian.QueryParser.FLAG_PARTIAL
)
HAYSTACK_XAPIAN_STEMMING_STRATEGY = 'STEM_ALL'

HAYSTACK_CONNECTIONS = {
    'default': {
        'ENGINE': 'xapian_backend.XapianEngine',
        'PATH': root.path('data/xapian')(),
        'FLAGS': HAYSTACK_XAPIAN_FLAGS,
    },
}

Before these settings, I was having problem with queries being apparently case sensitive, at least when using AutoQuery, and failing partial searches. These changes improve case insensitivity and stemming, which still having almost 100x better performance than Whoosh.

Hopefully this helps someone out there looking for solutions.

When I started with Django, the version at the time was 1.5. Back then, we prepended STATIC_URL to our static assets to reference them in our templates. With recent release, best practice is to you use the static ^[1]. I often find myself wanting to append a version number to my static files, at least my CSS and JS files to ensure that browser see my new versions when I push an update. In this post, I make use of the `static` tag and its URL building to easily append a version number.

Read More

I present a sample settings.py for a Django project, setup to accomplish the following requirements.
Read More

Do you have a need to use different URL pattern sets based on specifics of an HTTP request? Recently, I needed to choose from a predefined URL pattern (ie. URLConf module) based on the domain name of the request, ie. HTTP_HOST. The URL patterns themselves are not dynamically set, just dynamically chosen.
Read More

I recently upgraded a Django project to version 1.8, and I am happily using Postgresql and Django’s new UUIDField. While using django-eztables to do the server-side work for DataTables.net, I ran into an issue with a UUID field.

Read More

If you’re using jQuery, and have an entire JSON document document that you would like to post to Django, the correct way to do it is not through a separate variable, but by posting the actual JSON.
Read More

If you’ve progressed beyond the exploration phase in your Django journey, you’ve probably come to the point where, at the least, you would like to use one database during your development, and another, once published to your production system. You may even want to

Read More

I recently upgraded a Django project from 1.4.x to 1.5.1, along with that came the anticipated change to ‘django.conf.urls’ which gives a deprecation warning on every request:

Read More