Django and monkey patching issue

Question

I have recently started experimenting with Django for some web applications in my spare time. While designing the data model for one, I came across the dilemma of using inheritance to define a user of the website or using a technique known as monkey patching with the User class already supplied by the framework.

I tried to add a field by means of (after having defined all my models etc. without errors, according to python manage.py validate):

User.add_to_class('location', models.CharField(max_length=250,blank=True))

and executed the syncdb command. However, I keep getting this error

OperationalError: no such column: auth_user.location

whether I am in the admin view of the site or the manage.py shell. There must be an extra step I'm missing, but there seems to be limited documentation on the whole monkey patching technique. So I'm asking you for assistance before I resort to inheritance. Any code, tips, or pointers to additional documentation are of course welcome.

Thanks in advance.

PS. I'm aware this technique is ugly, and probably ill-advised. ;)

Answer 1

Djangos framework uses metaclasses to initialize the tables. That means you can't monkey-patch in new columns, unless you also re-initialize the class, which I'm not sure is even possible. (It may be).

See http://stackoverflow.com/questions/1251294/difference-between-returning-modified-class-and-using-type/ for some more info.

Answer 2

I guess you might run into problems regarding where is your monkeypatch defined. I guess django syncdb creates databse tables only from the "pure" auth application, so your model will then be without "location", and then your site with the patch will look for the field.

Probably less painful way of adding additional info to user profiles is described in Django docs.

Answer 3

Here's a (slightly older) way of extending the User model.

Here's what the docs have to say.

And here's a recent conversation on django-users about the topic.

Answer 4

When you add a field to any model, even if you do it the 'official' way, you need to migrate the database - Django doesn't do it for you. Drop the table and run ./manage.py syncdb again.

You might want to investigate one of the migrations frameworks, such as south, which will manage this sort of thing for you.

Answer 5

There's an alternative to both approaches, which is to simply use a related profile model. This also happens to be a well-documented, highly recommended approach. Perhaps the reason that the add_to_class approach is not well-documented, as you noted, is because it's explicitly discouraged (for good reason).