Inspired by the question series 'Hidden features of ...', I am curious to hear about your favorite Django tips or lesser known but useful features you know of.

  • Please, include only one tip per answer.
  • Add Django version requirements if there are any.
+117  A: 

I'm just going to start with a tip from myself :)

Use os.path.dirname() in to avoid hardcoded dirnames.

Don't hardcode path's in your if you want to run your project in different locations. Use the following code in if your templates and static files are located within the Django project directory:

import os
PROJECT_DIR = os.path.dirname(__file__)
STATIC_DOC_ROOT = os.path.join(PROJECT_DIR, "static")
    os.path.join(PROJECT_DIR, "templates"),

Credits: I got this tip from the screencast 'Django From the Ground Up'.

Hmm, I never thought of that... usually I downvote people who answer their own questions, but this one is actually useful.
R. Bemrose
You shouldn't downvote people that answer their own questions. It is encouraged, even if it is pre-determined.
Paolo Bergantino
This is such a good idea that I still have a hard time understanding why it's not default. How many folks test and deploy on the same machine?
The leading slash in the 2nd argument to join() will cause those paths to be relative to the root. ie /static/ /home/user/static/
You're right, thanks for the hint.
I don't understand why this isn't a default.
Andrew Rimmer
This alleviates you from always type os.path.join() which gets annoying pretty fast: `j = lambda filename: os.path.join(PROJECT_DIR, filename)`. Then you just need to type `j("static")`.
If you are on Windows then replace the backslashes:os.path.join(PROJECT_DIR, "templates").replace('\\','/')
Peter Mortensen
@Peter Mortensen - why?
Dominic Rodger
@Dominic, "When specifying the path, always use forward slashes, even on Windows (e.g. C:/homes/user/mysite/sqlite3.db)." from here:
Vulcan Eager
@Agnel - why? I do all my Django development on Windows (before deploying to a Linux box), and have never ever had a problem with just using the output of `os.path.join`. What problems might you expect me to see?
Dominic Rodger
@Dominic, I must confess that I'm a newbie to Django... it's just what I read in the tutorial. You may be right.
Vulcan Eager
If you really like to get this fixed in Django leave a comment to asking core devs to reconsider the `wontfix` decision.
Sorin Sbarnea
you should import os and not os.path a per the python documentation.
Jorge Vargas
@Jorge Vargas, right, thanks.
+1 great tip Haes ! thanks
+85  A: 

Use django-annoying's render_to decorator instead of render_to_response.

def foo(request):
    bar = Bar.object.all()
    return {'bar': bar}

# equals to
def foo(request):
    bar = Bar.object.all()
    return render_to_response('template.html',
                              {'bar': bar},
Interesting. Thanks.
How do U pass the request context?
Lakshman Prasad
@becomingGuru - it happens automatically.
Dominic Rodger
This is fine, unless you are returning some HttpResponseRedirect()s and some render_to_response()s. Then the redirects fail.
Matthew Schinckel
Project has moved to:
Really nice improvement, although not really part of django...
@becomingGuru the manual passing of request contexts is such a chore that one wonders why there was no builtin way to do it from the get-go. It would be surprising if the problem weren't automatically solved.
David Berger
Nice, they should add a direct_to decorator as well (equivalent to direct_to_response).
I don't like it. "Explicit is better than implicit". The decorator is not telling when exactly it is going to render_to.
Tamás Szelei
schweeeet feature!
Meh, I like the direct_to_template generic view better as a replacement for render_to_template in my views.
Stijn Debrouwere
@Matthew Schinckel it actually doesn't mess up redirects - if you return an HttpResponse object it just passes it along without modifying it
+26  A: 

I like to use the Python debugger pdb to debug Django projects.

This is a helpful link for learning how to use it:

This is a godsend. To give a little more info, just add this: "import pdb; pdb.set_trace()" on any line of your code. Refresh your page. It will hang. Now go to your terminal window where you are running the development server. It should now be a interactive shell where you can access all variables as they are at that point in your code where you pasted the debug code.
winpdb gives you a GUI debugger:
Luiz C.
Aptana with PyDev for me!
+27  A: 

Use Jinja2 alongside Django.

If you find the Django template language extremely restricting (like me!) then you don't have to be stuck with it. Django is flexible, and the template language is loosely coupled to the rest of the system, so just plug-in another template language and use it to render your http responses!

I use Jinja2, it's almost like a powered-up version of the django template language, it uses the same syntax, and allows you to use expressions in if statements! no more making a custom if-tags such as if_item_in_list! you can simply say %{ if item in list %}, or {% if object.field < 10 %}.

But that's not all; it has many more features to ease template creation, that I can't go though all of them in here.

hasen j
I use and enjoy Jinja2 as well, but I've found that there are some couplings to the "contrib" applications. Particularly, the admin tool is pretty heavily tied to Django templates. Also, I had to recreate the login decorators in contrib.auth to be Jinja2 friendly, but not too hard.
Joe Holloway
Don't replace the template system with jinja2, just "add" it, don't remove the django templtes. Use Jinja2 for your own views, and let the admin interface continue to use the django template language.
hasen j
I agree hartily with this. Django's limited syntax is tolerable, most of the time, but when you get to the point of making custom tags and find out just how hard that actually is, Jinja2 is a breath of fresh air
Also, if you want to do *any* metaprogramming on template source, Jinja2 is much more pleasant, since you can directly access the AST of parsed templates. Walking the AST makes tasks like finding out which templates extend a base template, or listing the unbound variables in a template source block, almost trivially easy.
Thankfully in Django 1.2 the IF tag is alot smarter
Make sure to set TEMPLATE_DEBUG = False in For some reason TEMPLATE_DEBUG == True gives you cryptic error messages.
+26  A: 

Add assert False in your view code to dump debug information.

Or just type some random shit and screw the syntax! ;)
Lakshman Prasad
I think assert False is more intuitive =D
if you're running your project in the django dev server, use python's pdb module. It's a much more powerful way to debug:import pdb; pdb.stack_trace()
pdb is very useful, you are likely to have your connections time out unless you're very fast at debugging.
I always use `5 / 0` myself. Why five? No idea.
@StephenPaulger really? My browser (firefox /w firebug) seems content to wait several minutes for a response while I debug.
+72  A: 

Install Django Command Extensions and pygraphviz and then issue the following command to get a really nice looking Django model visualization:

./ graph_models -a -g -o my_project.png

Here's an example output from the Django Command Extensions page.

Cool tip. Thanks.
Nice, couldn't get the pygraphviz to install correctly in windows, but can still covert from the dot file using graphviz.
Coolest. Tip. Evar. :)
I love sharing model diagrams with this definitely a +1
+51  A: 

Don't hard-code your URLs!

Use url names instead, and the reverse function to get the URL itself.

When you define your URL mappings, give names to your URLs.

urlpatterns += ('project.application.views'
   url( r'^something/$', 'view_function', name="url-name" ),

Make sure the name is unique per URL.

I usually have a consistent format "project-appplication-view", e.g. "cbx-forum-thread" for a thread view.

UPDATE (shamelessly stealing ayaz's addition):

This name can be used in templates with the url tag.

hasen j
I agree 100% on this one. I started out using hard coded urls, and it bit me on a project when I changed the url format around a bit to accommodate some changes. I took the time to go back and dig through everything and replace hard coded urls. My only big complaint is that url tag errors kill the whole page while hard coded only messes up the individual link.
This shouldn't be a hidden feature, this is best practice and the only way to fly.
@skyl It's hardly "the only way to fly". I was at a Django dev sprint and Adrian Holovaty (one of the creators of Django) said he doesn't even use the `url` tag... His stance is that urls shouldn't be changing anyway (if you want to be friendly to your users).
you can use this in templates, too, as in `{% url arg1 arg2 %}`
If you use jinja2, just add `reverse` like this `environment.filters['url'] = django.core.urlresolvers.reverse` and you can use it in your templates like so: `{{ 'view-name'|url(arg1, arg2)|e }}` (the "e" is needed to escape some characters for inclusion in HTML)
+40  A: 

Don't write your own login pages. If you're using django.contrib.auth.

The real, dirty secret is that if you're also using django.contrib.admin, and django.template.loaders.app_directories.load_template_source is in your template loaders, you can get your templates free too!

# somewhere in
urlpatterns += patterns('django.contrib.auth',
    (r'^accounts/login/$','views.login', {'template_name': 'admin/login.html'}),
Cool! I didn't know that we can reuse the admins login page. Thanks!
+13  A: 

django.views.generic.list_detail.object_list -- It provides all the logic & template variables for pagination (one of those I've-written-that-a-thousand-times-now drudgeries). Wrapping it allows for any logic you need. This gem has saved me many hours of debugging off-by-one errors in my "Search Results" pages and makes the view code cleaner in the process.

You can find the new version of the book's chapter on Generic Views on . The one on the comment goes to the Django pre-1.0 version of the book (Django book 1.0)
+20  A: 

This adds to the reply above about Django URL names and reverse URL dispatching.

The URL names can also be effectively used within templates. For example, for a given URL pattern:

url(r'(?P<project_id>\d+)/team/$', 'project_team', name='project_team')

you can have the following in templates:

<a href="{% url project_team %}">Team</a>
+36  A: 

When I was starting out, I didn't know that there was a Paginator, make sure you know of its existence!!

hasen j
:D same for me! I spent days on paginating!
+24  A: 

When trying to exchange data between Django and another application, request.raw_post_data is a good friend. Use it to receive and custom-process, say, XML data.


THATS How you do it. Thankyou, +1
+12  A: 

django.db.models.get_model does allow you to retrieve a model without importing it.

James shows how handy it can be: "Django tips: Write better template tags — Iteration 4 ".

+3  A: 

Render form via django template instead of as_(ul|table|p)().

This article shows, how to use template to render CusstomForms instead of as_p(), as_table()...

To make it work change

  • from django import newforms as forms to from django import forms
  • from django.newforms.forms import BoundField to from django.forms.forms import BoundField
+1  A: 

Use isapi-wsgi and django-pyodbc to run Django on Windows using IIS and SQL Server!

Jason Baker
+13  A: 

The webdesign app is very useful when starting to design your website. Once imported, you can add this to generate sample text:

{% load webdesign %}
{% lorem 5 p %}
FYI, for anyone using Jinja2 instead of Django templates, you can do: {{ lipsum(5) }}
Joe Holloway
+53  A: 

There's a set of custom tags I use all over my site's templates. Looking for a way to autoload it (DRY, remember?), I found the following:

from django import template

If you put this in a module that's loaded by default (your main urlconf for instance), you'll have the tags and filters from your custom tag module available in any template, without using {% load custom_tag_module %}.

The argument passed to template.add_to_builtins() can be any module path; your custom tag module doesn't have to live in a specific application. For example, it can also be a module in your project's root directory (eg. 'project.custom_tag_module').

This really owns. Thanks.
@Steef, you just saved me loads of time/heartache/bytes, thanks.
Really nice. Thanks.Also a repository of custom tags would be great to share stuff, dont you think?
Leandro Ardissone
+45  A: 

Virtualenv + Python = life saver if you are working on multiple Django projects and there is a possibility that they all don't depend on the same version of Django/an application.

This is ONLY way to roll!
yep, the only way
Could you add some tutorial links for virtualenv with django?
+39  A: 

Use django debug toolbar. For example, it allows to view all SQL queries performed while rendering view and you can also view stacktrace for any of them.

Eugene Morozov
Which is now at
+16  A: 

I don't have enough reputation to reply to the comment in question, but it's important to note that if you're going to use Jinja, it does NOT support the '-' character in template block names, while Django does. This caused me a lot of problems and wasted time trying to track down the very obscure error message it generated.

One note that may or may not be applicable to "obscure error messages from jinja". Make sure to set TEMPLATE_DEBUG = False in For some reason this will give you meaningful errors from Jinja templates.
+9  A: 

Just found this link: - "Django Best Practices".

Interesting site, but all that jumping of the page up and down makes me cringe.
+22  A: 

From the django-admin documentation:

If you use the Bash shell, consider installing the Django bash completion script, which lives in extras/django_bash_completion in the Django distribution. It enables tab-completion of and commands, so you can, for instance...

  • Type
  • Press [TAB] to see all available options.
  • Type sql, then [TAB], to see all available options whose names start with sql.
+27  A: 

Context processors are awesome.

Say you have a different user model and you want to include that in every response. Instead of doing this:

def myview(request, arg, arg2=None, template='my/template.html'):
    ''' My view... '''
    response = dict()
    myuser = MyUser.objects.get(user=request.user)
    response['my_user'] = myuser
    return render_to_response(template,

Context processes give you the ability to pass any variable to your templates. I typically put mine in 'my_project/apps/core/

def my_context(request):
        return dict(my_user=MyUser.objects.get(user=request.user))
    except ObjectNotFound:
        return dict(my_user='')

In your add the following line to your TEMPLATE_CONTEXT_PROCESSORS


Now every time a request is made it includes the my_user key automatically.

Also signals win.

I wrote a blog post about this a few months ago so I'm just going to cut and paste:

Out of the box Django gives you several signals that are incredibly useful. You have the ability to do things pre and post save, init, delete, or even when a request is being processed. So lets get away from the concepts and demonstrate how these are used. Say we’ve got a blog

class Post(models.Model):
    title = models.CharField(_('title'), max_length=255)
    body = models.TextField(_('body'))
    created = models.DateTimeField(auto_now_add=True)

So somehow you want to notify one of the many blog-pinging services we’ve made a new post, rebuild the most recent posts cache, and tweet about it. Well with signals you have the ability to do all of this without having to add any methods to the Post class.

import twitter

from django.core.cache import cache
from django.db.models.signals import post_save
from django.conf import settings

def posted_blog(sender, created=None, instance=None, **kwargs):
    ''' Listens for a blog post to save and alerts some services. '''
    if (created and instance is not None):
        tweet = 'New blog post! %s' instance.title
        t = twitter.PostUpdate(settings.TWITTER_USER,
        cache.set(instance.cache_key, instance, 60*5)
       # send pingbacks
       # ...
       # whatever else
post_save.connect(posted_blog, sender=Post)

There we go, by defining that function and using the post_init signal to connect the function to the Post model and execute it after it has been saved.

Django's Signals are a must-have feature for me these days, when comparing web frameworks. Writing a loosely coupled forum, say, that can listen for, say, updates from a "signature" module, but not actually require that module to work, and that can also work with compatible modules implementing the same feature, is great. I don't know why signals aren't more well known and popular.
Lee B
all kinds of fun with signals:
Signals are very important to avoid tight coupling and code mess in general if we use some reusable apps in our project. You provided an excellent example for loose coupling of django apps, +1 for this.
Łukasz Korzybski
+1. That's excellent, thanks a lot!
Do you know if signals are async ?
+12  A: 

I learned this one from the documentation for the sorl-thumbnails app. You can use the "as" keyword in template tags to use the results of the call elsewhere in your template.

For example:

{% url image-processor uid as img_src %}
<img src="{% thumbnail img_src 100x100 %}"/>

This is mentioned in passing in the Django templatetag documentation, but in reference to loops only. They don't call out that you can use this elsewhere (anywhere?) as well.

Joe Kueser
If a keyword as "as" can be used with a template-tag depends of this particular tag. It is not defined by django itself but by single tags, depending on their meaning. Have a look in the mentioned url-tag to see how "as" is used:
+20  A: 

Since Django "views" only need to be callables that return an HttpResponse, you can easily create class-based views like those in Ruby on Rails and other frameworks.

There are several ways to create class-based views, here's my favorite:

from django import http

class RestView(object):
    methods = ('GET', 'HEAD')

    def dispatch(cls, request, *args, **kwargs):
        resource = cls()
        if request.method.lower() not in (method.lower() for method in resource.methods):
            return http.HttpResponseNotAllowed(resource.methods)
            method = getattr(resource, request.method.lower())
        except AttributeError:
            raise Exception("View method `%s` does not exist." % request.method.lower())
        if not callable(method):
            raise Exception("View method `%s` is not callable." % request.method.lower())
        return method(request, *args, **kwargs)

    def get(self, request, *args, **kwargs):
        return http.HttpResponse()

    def head(self, request, *args, **kwargs):
        response = self.get(request, *args, **kwargs)
        response.content = ''
        return response

You can add all sorts of other stuff like conditional request handling and authorization in your base view.

Once you've got your views setup your will look something like this:

from django.conf.urls.defaults import *
from views import MyRestView

urlpatterns = patterns('',
    (r'^restview/', MyRestView.dispatch),
FWIW, the django authors actually use class-based views in a few places, e.g. contrib.formtools:
If you add a __call__ method you could create a class called RestfulResource and then have your point to instances.
+8  A: 

Use signals to add accessor-methods on-the-fly.

I saw this technique in django-photologue: For any Size object added, the post_init signal will add the corresponding methods to the Image model. If you add a site giant, the methods to retrieve the picture in giant resolution will be image.get_giant_url().

The methods are generated by calling add_accessor_methods from the post_init signal:

def add_accessor_methods(self, *args, **kwargs):
    for size in PhotoSizeCache().sizes.keys():
        setattr(self, 'get_%s_size' % size,
                curry(self._get_SIZE_size, size=size))
        setattr(self, 'get_%s_photosize' % size,
                curry(self._get_SIZE_photosize, size=size))
        setattr(self, 'get_%s_url' % size,
                curry(self._get_SIZE_url, size=size))
        setattr(self, 'get_%s_filename' % size,
                curry(self._get_SIZE_filename, size=size))

See the source code of photologue.models for real-world usage.


You can put print statements into your code to debug when using the dev server.

Remember to take them out before deploying to live as it slows down the server writing to Apache's log (if you use Apache). Consider using pdb instead or using Python's logging module or django-logging.
it can screw up certain deployment environments too
Wahnfrieden like using ipython in dev. This also of course needs to be taken out before deploying
consider using djangologging instead. your logging.debug('blah') etc. calls will be output to a special debugging window when DEBUG == True and when DEBUG == False, to whatever output you hve the logging module using.
+4  A: 

Use djangorecipe to manage your project

  • If you're writing a new app, this recipe makes testing it outside of a project really easy
  • It allows you to manage dependencies for a project (e.g. what version of some app it should depend on)

All you have to do to get started is this:

  1. Create a folder for your new website (or library)
  2. Create a buildout.cfg with following content in it:


  1. Grab a to get a local installation of buildout and place it within your directory. You can either go with the official one (sorry, Markdown didn't like part of the full link :-/ ) or with one that uses distribute instead of setuptools as described by Reinout van Rees.
  2. python (or python if you want to use distribute).
  3. ./bin/buildout

That's it. You should now have a new folder "my_new_site", which is your new django 1.1.1 project, and in ./bin you will find the django-script which replaces the on a normal installation.

What's the benefit? Let's say you want to use something like django-comment-spamfighter in your project. All you'd have to do is change your buildout.cfg to something like this:



Note that all I did was to add the last 2 lines which say, that the django-part should also have the django-comments-spamfighter package in version 0.4. The next time you run ./bin/buildout, buildout will download that package and modify ./bin/django to add it to its PYTHONPATH.

djangorecipe is also suited for deploying your project with mod_wsgi. Just add the wsgi=true setting to the django-part of your buildout.cfg and a "django.wsgi" will appear in your ./bin folder :-)

And if you set the test option to a list of applications, the djangorecipe will create a nice wrapper for you that runs all the tests for the listed application in your project.

If you want to develop a single app in a standalone environment for debugging etc., Jakob Kaplan-Moss has a quite complete tutorial on his blog

Horst Gutmann
+19  A: 

Instead of using render_to_response to bind your context to a template and render it (which is what the Django docs usually show) use the generic view direct_to_template. It does the same thing that render_to_response does but it also automatically adds RequestContext to the template context, implicitly allowing context processors to be used. You can do this manually using render_to_response, but why bother? It's just another step to remember and another LOC. Besides making use of context processors, having RequestContext in your template allows you to do things like:

<a href="{{MEDIA_URL}}images/frog.jpg">A frog</a>

which is very useful. In fact, +1 on generic views in general. The Django docs mostly show them as shortcuts for not even having a file for simple apps, but you can also use them inside your own view functions:

from django.views.generic import simple

def article_detail(request, slug=None):
    article = get_object_or_404(Article, slug=slug)
    return simple.direct_to_template(request, 
        extra_context={'article': article}
Save even more LOC by using the @render_to decorator available in django-annoying.
+4  A: 

Instead of running the Django dev server on localhost, run it on a proper network interface. For example:

python runserver


python runserver

Then you can not only easily use Fiddler ( or another tool like HTTP Debugger ( to inspect your HTTP headers, but you can also access your dev site from other machines on your LAN to test.

Make sure you are protected by a firewall though, although the dev server is minimal and relatively safe.

"Relatively" is a good word, once I exposed the built-in static assets serving to the outer word and regret it. While technically it's not devserver-related, it's within the same piece of code - Django, so I would extrapolate this experience to the devserver as well.
Tomasz Zielinski
+26  A: 

Use IPython to jump into your code at any level and debug using the power of IPython. Once you have installed IPython just put this code in wherever you want to debug:

from IPython.Shell import IPShellEmbed; IPShellEmbed()()

Then, refresh the page, go to your runserver window and you will be in an interactive IPython window.

I have a snippet set up in TextMate so I just type ipshell and hit tab. I couldn't live without it.

Better install `ipdb` and then just type `ipdb.set_trace()`
Tomasz Zielinski
+1  A: 

This is a really easy way to never have to import another one of your models again in your python shell.

First, install IPython (If you don't use IPython, what's wrong with you?). Next, create a python script,, in your django project directory with the following code in it:

from django.db.models.loading import get_models 
for m in get_models(): 
     globals()[m.__name__] = m 
#NOTE: if you have two models with the same name you'll only end up with one of them

Then, in your ~/.ipython/ipythonrc file, put the following code in the "Python files to load and execute" section:

execfile /path/to/project/

Now every time you start up IPython or run ./ shell you will have all your models already imported and ready to use. No need to ever import another model again.

You can also put any other code you execute a lot in your file to save yourself time.

consider using "django command extensions" which which adds the ./ shell_plus command which does this for you (several other cool stuff, too.)
+10  A: 

Everybody knows there is a development server you can run with " runserver", but did you know that there is a development view for serving static files (CSS / JS / IMG) as well ?

Newcomers are always puzzled because Django doesn't come with any way to serve static files. This is because the dev team think it is the job for a real life Web server.

But when developing, you may not want to set up Apache + mod_wisgi, it's heavy. Then you can just add the following to

(r'^site_media/(?P<path>.*)$', 'django.views.static.serve',
        {'document_root': '/path/to/media'}),

Your CSS / JS / IMG will be available at

Of course, don't use it in a production environment.

Never ever use it in a production environment - it's wide open for hackers (writing this from my own experience).
Tomasz Zielinski
That what I wrote at the end of the answer...
+14  A: 

Run a development SMTP server that will just output whatever is sent to it (if you don't want to actually install SMTP on your dev server.)

command line:

python -m smtpd -n -c DebuggingServer localhost:1025
you can use console and file email backends in django 1.2 for the same purpose
Dmitry Shevchenko
outstanding! perfect for registration! +1
+5  A: 

Use wraps decorator in custom views decorators to preserve view's name, module and docstring. E.g.

    from functools import wraps
except ImportError:
    from django.utils.functional import wraps  # Python 2.3, 2.4 fallback.

def view_decorator(fun):
    def wrapper():
        # here goes your decorator's code
    return wrapper

Beware: will not work on a class-based views (those with __call__ method definition), if the author hasn't defined a __name__ property. As a workaround use:

from django.utils.decorators import available_attrs
    @wraps(fun, assigned=available_attrs(fun))
+2  A: 

Changing Django form field properties on init

Sometimes it's useful to pass extra arguments to a Form class.

from django import forms
from mymodels import Group

class MyForm(forms.Form):

    def __init__(self,my_var,*args,**kwrds):
        self.fields['some_choices']=[[x,x] for x in list_of_stuff]

source: Dzone snippets

+2  A: 

PyCharm IDE is a nice environment to code and especially debug, with built-in support for Django.

+2  A: 

The Django Debug Toolbar is really fantastic. Not really a toolbar, it actually brings up a sidepane that tells you all sorts of information about what brought you the page you're looking at - DB queries, the context variables sent to the template, signals, and more.

Mark Snidovich
+7  A: 

Use xml_models to create Django models that use an XML REST API backend (instead of a SQL one). This is very useful especially when modelling third party APIs - you get all the same QuerySet syntax that you're used to. You can install it from PyPI.

XML from an API:

<profile id=4>
    <email>[email protected]</email>

And now in python:

class Profile(xml_models.Model):
    user_id = xml_models.IntField(xpath='/profile/@id')
    email = xml_models.CharField(xpath='/profile/email')
    first = xml_models.CharField(xpath='/profile/first_name')
    last = xml_models.CharField(xpath='/profile/last_name')
    birthday = xml_models.DateField(xpath='/profile/date_of_birth')

    finders = {
        (user_id,):  settings.API_URL +'/api/v1/profile/userid/%s',
        (email,):  settings.API_URL +'/api/v1/profile/email/%s',

profile = Profile.objects.get(user_id=4)
# would print '[email protected]'

It can also handle relationships and collections. We use it every day in heavily used production code, so even though it's beta it's very usable. It also has a good set of stubs that you can use in your tests.

(Disclaimer: while I'm not the author of this library, I am now a committer, having made a few minor commits)

interesting project, keep it up!
Thanks, it's pretty handy :-)
+5  A: 

Use reverse in your urlconf.

This is one of those tricks where I don't understand why it isn't the default.

Here's a link to where I picked it up:

Here's the code snippet:

from django.conf.urls.defaults import *
from django.core.urlresolvers import reverse
from django.utils.functional import lazy
from django.http import HttpResponse

reverse_lazy = lazy(reverse, str)

urlpatterns = patterns('',
url(r'^comehere/', lambda request: HttpResponse('Welcome!'), name='comehere'),
url(r'^$', 'django.views.generic.simple.redirect_to',
{'url': reverse_lazy('comehere')}, name='root')
What does that mean and why would I want to do it?
Dominic Rodger
Reverse is like the URL tag, which "Returns an absolute URL (i.e., a URL without the domain name) matching a given view function and optional parameters." I avoid harding code absolute URLs. When I go to deploy on a web server, the app may not be the root mount point, so in the test server a URL like /app/url/ might work, but on the deploy server it might be /mountpoint/app/url.Reverse works in But it doesn't work in It gives the error: "The included urlconf foo.urls doesn’t have any patterns in it". This trick saves you from needing to wrap the URLconf in a view.
+1  A: 

Create dynamic models for sets of legacy tables with the same structure:

class BaseStructure(models.Model):
    name = models.CharField(max_length=100)
    address = models.CharField(max_length=100)

    class Meta:

class DynamicTable(models.Model):
    table_name = models.CharField(max_length=20)

    def get_model(self):
        class Meta:

        attrs = {}
        attrs['Meta'] = Meta

        # type(new_class_name, (base,classes), {extra: attributes})
        dynamic_class = type(self.table_name, (BaseStructure,), attrs) 
        return dynamic_class

customers = DynamicTable.objects.get(table_name='Customers').get_model()
me = customers.objects.get(name='Josh Smeaton')
me.address = 'Over the rainbow'

This assumes that you have legacy tables with the same structure. Instead of creating a model to wrap each of the tables, you define one base model, and dynamically construct the class needed to interact with a specific table.

Josh Smeaton
+4  A: 

Remove Database Access Information from

One thing I've done in my Django site's is load database access info from a file in /etc. This way the access setup (database host, port, username, password) can be different for each machine, and sensitive info like the password isn't in my project's repository. You might want to restrict access to the workers in a similar manner, by making them connect with a different username.

You could also pass in the database connection information, or even just a key or path to a configuration file, via environment variables, and handle it in

For example, here's how I pull in my database configuration file:

g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
    DATABASES = dbSetup['databases']
        'default': {
            'ENGINE': 'django.db.backends.mysql',
            # ...

Needless to say, you need to make sure that the file in DB_CONFIG is not accessible to any user besides the db admins and Django itself. The default case should refer Django to a developer's own test database. There may also be a better solution using the ast module instead of execfile, but I haven't researched it yet.

Another thing I do is use separate users for DB admin tasks vs. everything else. In my, I added the following preamble:

# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/django/'
dbConfFile = '/etc/django/'
import sys
import os
def goodFile(path):
    return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
    and goodFile(adminDBConfFile):
    os.environ['DB_CONFIG'] = adminDBConfFile
elif goodFile(dbConfFile):
    os.environ['DB_CONFIG'] = dbConfFile

Where the config in /etc/django/ is for a user with access to only the Django database with SELECT, INSERT, UPDATE, and DELETE, and /etc/django/ is for a user with these permissions plus CREATE, DROP, INDEX, ALTER, and LOCK TABLES. (The migrate command is from South.) This gives me some protection from Django code messing with my schema at runtime, and it limits the damage an SQL injection attack can cause (though you should still check and filter all user input).

(Copied from my answer to another question)

Mike DeSimone