annotate content/Coding/027-upgrading-django1.6.rst @ 5:4b5cdcc351c5

Use a cloned copy of pelican-bootstrap3 repo as my theme.
author Brian Neal <bgneal@gmail.com>
date Fri, 31 Jan 2014 19:12:50 -0600
parents 7ce6393e6d30
children 49bebfa6f9d3
rev   line source
bgneal@4 1 Upgrading to Django 1.6
bgneal@4 2 #######################
bgneal@4 3
bgneal@4 4 :date: 2013-12-29 18:00
bgneal@4 5 :tags: Django
bgneal@4 6 :slug: upgrading-to-django-1.6
bgneal@4 7 :author: Brian Neal
bgneal@4 8
bgneal@4 9 Getting started
bgneal@4 10 ===============
bgneal@4 11
bgneal@4 12 `Django`_ 1.6 came out recently, which was soon followed by 1.6.1, and it looks
bgneal@4 13 like 1.6.2 is on the way. I finally got around to upgrading two of my largest
bgneal@4 14 sites. I thought I would make a list of what I changed at a high level for my
bgneal@4 15 own reference. Perhaps someone else may find it useful as well.
bgneal@4 16
bgneal@4 17 In any event, I highly recommend you read the excellent `release notes`_ and
bgneal@4 18 `deprecation timeline`_. The changes in 1.6 didn't seem groundbreaking, but
bgneal@4 19 they were numerous. I spent a lot of time reading through the notes and trying
bgneal@4 20 to decide if the issues affected me or not.
bgneal@4 21
bgneal@4 22 I recommend you run with warnings turned on::
bgneal@4 23
bgneal@4 24 $ python -Wall manage.py runserver
bgneal@4 25
bgneal@4 26 This will help you flag down issues in your code. If you aren't sure where
bgneal@4 27 a warning is coming from, you can turn warnings into exceptions and get
bgneal@4 28 a traceback (see the Python docs on the warnings_ library). Another trick is to
bgneal@4 29 put a pdb_ breakpoint in the Django code before or after the warning, then you
bgneal@4 30 can examine the call stack with the ``w`` command.
bgneal@4 31
bgneal@4 32 Upgrade Issues
bgneal@4 33 ==============
bgneal@4 34
bgneal@4 35 Here are the issues that I ran into. Of course you may have a very different
bgneal@4 36 experience depending on what features of Django you used and the details of
bgneal@4 37 your site.
bgneal@4 38
bgneal@4 39 #. The location of the ``XViewMiddleware`` changed. I had to update my
bgneal@4 40 ``MIDDLEWARE_CLASSES`` setting as a result.
bgneal@4 41 #. Various ``get_query_set`` to ``get_queryset`` changes. The Django developers
bgneal@4 42 have ironed out some naming inconsistencies in method names on both model
bgneal@4 43 managers and ``ModelAdmin`` classes.
bgneal@4 44 #. In template / form processing, the ``label_tag`` now includes the
bgneal@4 45 ``label_suffix``. I noticed this when I saw that I had two colons on a form
bgneal@4 46 field's label.
bgneal@4 47 #. One very nice change that I am please to see is that Django now does test
bgneal@4 48 discovery just like the unittest_ module in the standard library. To take
bgneal@4 49 advantage of this I renamed all my test modules from ``view_tests.py`` to
bgneal@4 50 ``test_views.py``, for example. This also let me get rid of ``import``
bgneal@4 51 statements in various ``__init__.py`` files in test subdirectories. In other
bgneal@4 52 words, you no longer have to have silly lines like
bgneal@4 53 ``from view_tests import *`` in your test packages' ``__init__.py`` files.
bgneal@4 54 #. Django now supports database connection persistence. To take advantage of
bgneal@4 55 this you need to set the CONN_MAX_AGE_ setting to a non-zero value.
bgneal@4 56 #. The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting is now deprecated and can be
bgneal@4 57 removed. For various reasons explained in the notes this never really worked
bgneal@4 58 right anyway.
bgneal@4 59 #. Updated to version 1.0 of the django-debug-toolbar_. The version I was using
bgneal@4 60 would not work in Django 1.6. It is so good to see that this project is
bgneal@4 61 being actively maintained again. There are several new panels and neat
bgneal@4 62 features, check it out!
bgneal@4 63 #. You now get a warning if you have a ``ModelForm`` without an ``exclude`` or
bgneal@4 64 ``fields`` meta option. This is rather nice as I have been bit by this in
bgneal@4 65 the past when a form suddenly started showing a newly added field that it
bgneal@4 66 should not have. I added a ``fields`` option to a ``ModelForm`` as a result.
bgneal@4 67 Unfortunately some third party applications I am using have this problem as
bgneal@4 68 well.
bgneal@4 69 #. The ``cycle`` tag has new XSS_ protection. To make use of it now, you have
bgneal@4 70 to add a ``{% load cycle from future %}`` tag into your templates.
bgneal@4 71 #. The ``django.contrib.auth`` password reset function is now using base 64 encoding of the
bgneal@4 72 ``User`` primary key. The details are `here <https://docs.djangoproject.com/en/1.6/releases/1.6/#django-contrib-auth-password-reset-uses-base-64-encoding-of-user-pk>`_. This affected me
bgneal@4 73 because I am using a custom password reset URL, and thus I needed to update
bgneal@4 74 my URL pattern for both the new parameter name and the regular expression
bgneal@4 75 for base 64. I missed this originally and I started getting 404's on my
bgneal@4 76 password reset confirmation URLs. And yes, this is something I should have a
bgneal@4 77 test for!
bgneal@4 78
bgneal@4 79 What I didn't do
bgneal@4 80 ================
bgneal@4 81
bgneal@4 82 Many of the warnings that I got came from third party modules that I have not
bgneal@4 83 updated in a long time, including Celery_ and Haystack_. I am going to have to
bgneal@4 84 schedule some time to update to the latest versions of these apps. Hopefully
bgneal@4 85 the warnings will be fixed in the newer versions, but if not I can write
bgneal@4 86 tickets or possibly submit patches / pull requests. This is the price of
bgneal@4 87 progress I suppose.
bgneal@4 88
bgneal@4 89 I also use a couple of smaller third party applications that seem to be no
bgneal@4 90 longer maintained. These apps are now generating some warnings. I'll have to
bgneal@4 91 fork them and fix these myself. Luckily these projects are on GitHub so this
bgneal@4 92 should not be a problem.
bgneal@4 93
bgneal@4 94 Finally I am still facing the problem of what to do about the deprecation of
bgneal@4 95 the ``AUTH_PROFILE_MODULE`` and the ``get_profile`` method. This will be
bgneal@4 96 removed in Django 1.7. I've been doing some more reading about this and I'm
bgneal@4 97 less scared about this than I used to. I'll probably just change my profile
bgneal@4 98 model to have a one-to-one relationship with the provided ``User`` model. I'll
bgneal@4 99 have to do some more researching and thinking about this before Django 1.7.
bgneal@4 100
bgneal@4 101
bgneal@4 102 Conclusion
bgneal@4 103 ==========
bgneal@4 104
bgneal@4 105 Once again the upgrade process went smoother and quicker than I thought thanks
bgneal@4 106 to the excellent release notes and the Django team's use of Python warnings to
bgneal@4 107 flag deprecated features.
bgneal@4 108
bgneal@4 109
bgneal@4 110 .. _Django: https://www.djangoproject.com/
bgneal@4 111 .. _release notes: https://docs.djangoproject.com/en/1.6/releases/1.6/
bgneal@4 112 .. _deprecation timeline: https://docs.djangoproject.com/en/1.6/internals/deprecation/
bgneal@4 113 .. _warnings: http://docs.python.org/library/warnings.html
bgneal@4 114 .. _pdb: http://docs.python.org/library/pdb.html
bgneal@4 115 .. _unittest: http://docs.python.org/2/library/unittest.html
bgneal@4 116 .. _CONN_MAX_AGE: https://docs.djangoproject.com/en/1.6/ref/settings/#conn-max-age
bgneal@4 117 .. _XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
bgneal@4 118 .. _configurable user model: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user
bgneal@4 119 .. _django-debug-toolbar: https://pypi.python.org/pypi/django-debug-toolbar
bgneal@4 120 .. _Celery: http://www.celeryproject.org/
bgneal@4 121 .. _Haystack: http://haystacksearch.org/