Date Tags Django

Getting started

Django 1.6 came out recently, which was soon followed by 1.6.1, and it looks like 1.6.2 is on the way. I finally got around to upgrading two of my largest sites. I thought I would make a list of what I changed at a high level for my own reference. Perhaps someone else may find it useful as well.

In any event, I highly recommend you read the excellent release notes and deprecation timeline. The changes in 1.6 didn't seem groundbreaking, but they were numerous. I spent a lot of time reading through the notes and trying to decide if the issues affected me or not.

I recommend you run with warnings turned on:

$ python -Wall manage.py runserver

This will help you flag down issues in your code. If you aren't sure where a warning is coming from, you can turn warnings into exceptions and get a traceback (see the Python docs on the warnings library). Another trick is to put a pdb breakpoint in the Django code before or after the warning, then you can examine the call stack with the w command.

Upgrade Issues

Here are the issues that I ran into. Of course you may have a very different experience depending on what features of Django you used and the details of your site.

  1. The location of the XViewMiddleware changed. I had to update my MIDDLEWARE_CLASSES setting as a result.
  2. Various get_query_set to get_queryset changes. The Django developers have ironed out some naming inconsistencies in method names on both model managers and ModelAdmin classes.
  3. In template / form processing, the label_tag now includes the label_suffix. I noticed this when I saw that I had two colons on a form field's label.
  4. One very nice change that I am please to see is that Django now does test discovery just like the unittest module in the standard library. To take advantage of this I renamed all my test modules from view_tests.py to test_views.py, for example. This also let me get rid of import statements in various __init__.py files in test subdirectories. In other words, you no longer have to have silly lines like from view_tests import * in your test packages' __init__.py files.
  5. Django now supports database connection persistence. To take advantage of this you need to set the CONN_MAX_AGE setting to a non-zero value.
  6. The CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting is now deprecated and can be removed. For various reasons explained in the notes this never really worked right anyway.
  7. Updated to version 1.0 of the django-debug-toolbar. The version I was using would not work in Django 1.6. It is so good to see that this project is being actively maintained again. There are several new panels and neat features, check it out!
  8. You now get a warning if you have a ModelForm without an exclude or fields meta option. This is rather nice as I have been bit by this in the past when a form suddenly started showing a newly added field that it should not have. I added a fields option to a ModelForm as a result. Unfortunately some third party applications I am using have this problem as well.
  9. The cycle tag has new XSS protection. To make use of it now, you have to add a {% load cycle from future %} tag into your templates.
  10. The django.contrib.auth password reset function is now using base 64 encoding of the User primary key. The details are here. This affected me because I am using a custom password reset URL, and thus I needed to update my URL pattern for both the new parameter name and the regular expression for base 64. I missed this originally and I started getting 404's on my password reset confirmation URLs. And yes, this is something I should have a test for!

What I didn't do

Many of the warnings that I got came from third party modules that I have not updated in a long time, including Celery and Haystack. I am going to have to schedule some time to update to the latest versions of these apps. Hopefully the warnings will be fixed in the newer versions, but if not I can write tickets or possibly submit patches / pull requests. This is the price of progress I suppose.

I also use a couple of smaller third party applications that seem to be no longer maintained. These apps are now generating some warnings. I'll have to fork them and fix these myself. Luckily these projects are on GitHub so this should not be a problem.

Finally I am still facing the problem of what to do about the deprecation of the AUTH_PROFILE_MODULE and the get_profile method. This will be removed in Django 1.7. I've been doing some more reading about this and I'm less scared about this than I used to. I'll probably just change my profile model to have a one-to-one relationship with the provided User model. I'll have to do some more researching and thinking about this before Django 1.7.

Conclusion

Once again the upgrade process went smoother and quicker than I thought thanks to the excellent release notes and the Django team's use of Python warnings to flag deprecated features.


Comments

comments powered by Disqus