So at work recently, we started looking at switching our django setups from mod_python to mod_wsgi, as we kept having memory and cpu use issues with mod_python, and mod_wsgi was supposed to be far better with performance.

Well, it’s only been a day so far, but the results have been very promising. Our memory usage was cut in half, and load bottomed out.

Edit: this is daemon mode with threads=1

Initial testing showed more drastic improvements, so for anyone else testing, take initial results with a grain of salt

With that said, here are the actual results:

Just after switching:

A day after switching:

Too early to be absolutely sure that everything is working well, but it’s all looking good so far

I really have to agree with John Cleese…

Not too long ago at work, we added a few more servers to our production deployment to speed things up – however, this made deploying code changes a bit more complicated, as you had to remember to update several servers every time.  I decided to look into Capistrano, which I’d heard about before, and am glad to say it’s working very well, once I managed to figure it out.

The only problem with Capistrano is that it’s primarily used by rails devs, so all the examples I could ever find online were using it for rails, and mostly using the included ‘deploy’ script, which is very rails-centric with migrations and such. Since we’re using python and javascript in our projects, those things didn’t apply well.

After some digging I’ve managed to get a nice little deploy script that will update many servers to the latest tag in svn, and can also roll back to the next-latest tag, in case something goes wrong

role :example, "www.example.com", "www2.example.com", "www3.example.com"

set :destination, "/home/example/sources"
set :repository, "svn+ssh://svn.example.com/svn/oggllc"

def ls(path)
    `svn ls #{path}`
end

def previous_tag(component)
    logger.debug "querying previous #{component} tag..."
    tags_dir = "#{repository}/tags/#{component}/"
    ls(tags_dir).split("\n")[-2].chomp('/')
end

def latest_tag(component)
    logger.debug "querying latest #{component} tag..."
    tags_dir = "#{repository}/tags/#{component}/"
    ls(tags_dir).split("\n")[-1].chomp('/')
end

desc "Deploy latest example tag"
task :deploy_example, :roles => :example do
    set :latest_rev, latest_tag("example")
    logger.debug "latest tag: #{latest_rev}"
    run "cd #{destination}/example ; svn switch #{repository}/tags/example/#{latest_rev}"
    run "sudo apachectl restart"
end

desc "Rollback example to previous tag"
task :rollback_example, :roles => :example do
    set :previous_rev, previous_tag("example")
    logger.debug "previous tag: #{previous_rev}"
    run "cd #{destination}/example ; svn switch #{repository}/tags/example/#{previous_rev}"
    run "sudo apachectl restart"
end

Not much text to put in this post, I just want to show a few useful things you can do with a ModelForm in django, so I can quit retyping examples

1) Replace a widget without losing all the default values passed to the form field from the model definition:

from django import forms
from mysite.polls.models import Poll

class PollForm(forms.ModelForm):
    def __init__(self, *args, **kwargs):
        super(PollForm, self).__init__(*args, **kwargs)
        self.fields['question'].widget = forms.Textarea()

    class Meta:
        model = Poll

2) Along the same lines, limit the choices of a ForeignKey based on a user:

(assume we’ve added an owner field to the tutorial Poll model to indicate the User who created the Poll)

from datetime import datetime, timedelta
from django import forms
from mysite.polls.models import Poll, Choice

class ChoiceForm(forms.ModelForm):
    def __init__(self, user, *args, **kwargs):
        super(ChoiceForm, self).__init__(*args, **kwargs)
        self.fields['poll'].queryset = Poll.objects.filter(owner=user)

    class Meta:
        model = Choice

In this one, you would then call the form with request.user as the first argument:

form = ChoiceForm(request.user, request.POST)

or just

form = ChoiceForm(request.user)

3) Nothing yet, may expand this later.

Today my blog was hacked, erasing the most recent post in favor of spam links. Thankfully, I was able to recover it from Google’s cache, but I’m tired of all the issues maintaining my own blog.

As a result, I’ve decided to move my blog here, so that I don’t have to deal with the hassle anymore.

A common problem I see when helping people in the Django IRC channel is people who are trying to create or edit multiple objects, but for some reason try to make a single form object to deal with them – this makes things quite convoluted and much harder than they have to be. My goal here is to explain a much simpler method using multiple form objects.

For this guide, I’m going to use the basic Poll and Choice models from the tutorial. I’m only showing the fields here, as that’s all that matters to the form, but they wouldn’t break anything, of course

from django.db import models

class Poll(models.Model):
    question = models.CharField(max_length=200)
    pub_date = models.DateTimeField()

class Choice(models.Model):
    poll = models.ForeignKey(Poll)
    choice = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

To start, we’ll need forms for each model.

from django import forms
from mysite.polls.models import Poll, Choice

class PollForm(forms.ModelForm):
    class Meta:
        model = Poll

class ChoiceForm(forms.ModelForm):
    class Meta:
        model = Choice
        exclude = ('poll',)

By using ModelForm, all the grunt work of saving/updating is handled for us, so it saves a lot of work you’d have to code yourself when trying to use a single form.

Next up is the view, but here there’s one issue we have to avoid – if you simply make 3 ChoiceForm instances, their field names will conflict – since you’ll get 3 poll fields and 3 choice fields. To get around this, we need to use the prefix arg to the forms, as you’ll see in a moment.

from mysite.polls.models import Poll, Choice
from mysite.polls.forms import PollForm, ChoiceForm
from django.http import HttpResponseRedirect
from django.shortcuts import render_to_response

def add_poll(request):
    if request.method == "POST":
        pform = PollForm(request.POST, instance=Poll())
        cforms = [ChoiceForm(request.POST, prefix=str(x), instance=Choice()) for x in range(0,3)]
        if pform.is_valid() and all([cf.is_valid() for cf in cforms]):
            new_poll = pform.save()
            for cf in cforms:
                new_choice = cf.save(commit=False)
                new_choice.poll = new_poll
                new_choice.save()
            return HttpResponseRedirect('/polls/add/')
    else:
        pform = PollForm(instance=Poll())
        cforms = [ChoiceForm(prefix=str(x), instance=Choice()) for x in range(0,3)]
    return render_to_response('add_poll.html', {'poll_form': pform, 'choice_forms': cforms})

The basic structure is identical to when you’re adding a single object, with only a few differences. The first thing I’d like to point out is the prefix arg – by setting that, we get fields named 0-choice, 1-choice, and 2-choice instead of just 3 fields named choice. This allows each ChoiceForm to pick out its own data from request.POST, so they don’t conflict.

When checking if the forms are valid, I use all(), which will only return True if every item in the list evaluates to True as well. For those who like map(), you can replace the inner list comprehension with map(lambda x: x.is_valid(), cforms).

Note: It’s come to my attention that all() is new in 2.5, and I hadn’t been aware of that previously – a quick way to define your own is here:

def all(items):
    import operator
    return reduce(operator.and_, [bool(item) for item in items])

There may be other methods, but this should work fine

Finally, when saving the forms, we use commit=False on the ChoiceForm instances, so that we can set the poll ForeignKey properly before saving. The commit arg tells the form to create the new Choice instance and return it, but not save it to the database.

And with that, you now have a view which can add a Poll and 3 Choice objects for it at once.

Making a view to edit the same objects is much similar, you just need to query the Poll and Choice objects and use them instead of the empty instances. You can also use the Choice IDs as the prefixes for the ChoiceForm instances. The great thing with using ModelForm is that once you change the instance arg from a new object to an existing one, it becomes an edit form instead of an add form, so you don’t have to change any internals to go from adding to editing.

Updated 11/3/08 for django 1.0