Skip to content

aprendía

(I was learning)

auto_now_add is evil

Today I spent some time porting a year-old Django project to trunk. A lot has changed in Django within this last year, including auto-escaping, QSRF and NFA. Despite the changes I was pleasantly surprised at how few hiccups there were in changing over. In fact, I only hit one. I share it in hopes of saving someone else the hour that I have wasted.

In porting I used a handy newforms-admin admin.py generator, removed the inner Admin class from my models, altered my urls.py, and changed all references of from django import newforms as forms to simply from django import forms. Because of the simplicity of the project, that took care of everything but the templates. Or at least it should have.

Enter auto_now_add

Back when I made this project I was still a Django novice. Further, I had read much of James Bennett’s articles on the subject, but I didn’t realize that his advice should be heeded in most cases. I should have listened to this comment, wherein James lists the evils of auto_now_add including Jacob’s comment that auto_now_add should go away.

Nevertheless, I had a DateTimeField in one model that used the optional auto_now_add argument. Only after an hour of troubleshooting did I find that it was the cause of the error I was receiving.

…
Exception Type: ImproperlyConfigured at /admin/
Exception Value: Error while importing URLconf 'votestout.conf.urls': `SupporterAdmin.fieldsets[3][1]['fields']` refers to field `submit_date` that is missing from the form.

Fact was submit_date was not missing from the form. I had proved that too many times in too many ways. But after far too much mucking about with no results, I thought to remove the auto_now_add argument and voilà! All was well.

Can it go away now?

Django is changing rapidly as we approach 1.0. This is the time for backwards-incompatible changes. This seems the perfect time for auto_now and auto_now_add to go away. Unfortunately I don’t understand them well enough in a technical sense to submit a ticket and explain why they should leave, but in a practical sense I know they are evil. Developers can easily replace them by hand with the technique James suggests.