annotate content/Coding/025-upgrading-django1.5.rst @ 4:7ce6393e6d30

Adding converted blog posts from old blog.
author Brian Neal <bgneal@gmail.com>
date Thu, 30 Jan 2014 21:45:03 -0600
parents
children 49bebfa6f9d3
rev   line source
bgneal@4 1 Upgrading to Django 1.5
bgneal@4 2 #######################
bgneal@4 3
bgneal@4 4 :date: 2013-08-29 19:30
bgneal@4 5 :tags: Django
bgneal@4 6 :slug: upgrading-to-django-1.5
bgneal@4 7 :author: Brian Neal
bgneal@4 8
bgneal@4 9 Upgrading to Django 1.5
bgneal@4 10 =======================
bgneal@4 11
bgneal@4 12 `Django`_ 1.5 came out a while ago, and I finally got around to upgrading two
bgneal@4 13 of my largest sites. I thought I would make a list of what I changed at a high
bgneal@4 14 level for my own reference. Perhaps someone else may find it useful as well.
bgneal@4 15
bgneal@4 16 In any event, I highly recommend you read the excellent `release notes`_ and
bgneal@4 17 `deprecation timeline`_. I also recommend you run with warnings turned on::
bgneal@4 18
bgneal@4 19 $ python -Wall manage.py runserver
bgneal@4 20
bgneal@4 21 This will help you flag down issues in your code. If you aren't sure where
bgneal@4 22 a warning is coming from, you can turn warnings into exceptions and get
bgneal@4 23 a traceback (see the Python docs on the warnings_ library). Another trick is to
bgneal@4 24 put a pdb_ breakpoint in the Django code before or after the warning, then you
bgneal@4 25 can examine the call stack with the ``w`` command.
bgneal@4 26
bgneal@4 27 Upgrading Issues
bgneal@4 28 ================
bgneal@4 29
bgneal@4 30 Here are the issues that I ran into. Of course you may have a very different
bgneal@4 31 experience depending on what features of Django you used and the details of
bgneal@4 32 your site.
bgneal@4 33
bgneal@4 34 #. **Replace occurrences of Django's simplejson with json**. The Django team
bgneal@4 35 deprecated their version of the json library since they had dropped support
bgneal@4 36 for older versions of Python.
bgneal@4 37
bgneal@4 38 #. **select_related's depth argument is deprecated**. Instead of using
bgneal@4 39 ``depth`` I had to explictly name which relationships to follow.
bgneal@4 40
bgneal@4 41 #. **The cleanup management command is now called clearsessions**. I have
bgneal@4 42 a Celery_ task I had to update because of this name change.
bgneal@4 43
bgneal@4 44 #. **Remove my {% load url from future %} tags**. Long ago I had converted to
bgneal@4 45 the newer ``url`` tag behavior by using this tag. Since this is now the
bgneal@4 46 current behavior I could remove all of these tags.
bgneal@4 47
bgneal@4 48 #. **The LOGIN_* settings now accept URL names**. These settings can now accept
bgneal@4 49 URL names which allows me to be more DRY (Don't Repeat Yourself). I no
bgneal@4 50 longer have to maintain URL patterns in two places.
bgneal@4 51
bgneal@4 52 #. **Management commands should use self.stdout, etc. for output**. I'm not
bgneal@4 53 sure if this is required, but it makes it easier to test your management
bgneal@4 54 commands.
bgneal@4 55
bgneal@4 56 #. **slugify is now available at django.utils.text**. I was doing something
bgneal@4 57 kind of hacky by invoking the slugify template filter in Python code. Now
bgneal@4 58 this slugify code is more naturally available as a free Python function
bgneal@4 59 without the template filter baggage.
bgneal@4 60
bgneal@4 61 #. **Remove all references to django.contrib.markup**. Django decided not to be
bgneal@4 62 so tightly coupled to various third party markup languages. I can see their
bgneal@4 63 reasoning, as it does add to their maintenance burden, but it is kind of
bgneal@4 64 inconvenient if you already relied on it. Fortunately I had a while ago
bgneal@4 65 stopped relying on the Markdown filter and had used a custom solution.
bgneal@4 66 Seeing this issue in the release notes caused me to go looking through my
bgneal@4 67 code and I found some unused templates and ``INSTALLED_APPS`` setting that
bgneal@4 68 I could remove. On my second site, I had one tiny usage of the Textile
bgneal@4 69 filter that I decided to just get rid of since it was hardly worth carrying
bgneal@4 70 the dependency for. I wrote a quick and dirty management command to convert
bgneal@4 71 the database from storing Textile markup to HTML and I was done.
bgneal@4 72
bgneal@4 73 #. **localflavor is deprecated in preferece to a third party app**. I was using
bgneal@4 74 some US state fields in a few models. All I had to do was pip_ install
bgneal@4 75 `django-localflavor`_, fix up some imports, update my requirements files,
bgneal@4 76 and I was good.
bgneal@4 77
bgneal@4 78 #. **Function-based generic views are now gone**. A third party application
bgneal@4 79 I am using made use of the old function-based generic views. These have been
bgneal@4 80 replaced with the newer class-based generic views. Luckily I wasn't actually
bgneal@4 81 using the views in this application, I am only relying on it's models and
bgneal@4 82 utilities. In this case I simply removed the inclusion of the application's
bgneal@4 83 ``urls.py`` and all was well. The application is no longer maintained so
bgneal@4 84 I would have had to port to the class-based views if I had needed them.
bgneal@4 85
bgneal@4 86 #. **The adminmedia template tags library is now gone**. I wasn't actually
bgneal@4 87 using this anymore, but I had a template that was still loading it. This
bgneal@4 88 cruft was removed.
bgneal@4 89
bgneal@4 90 What I didn't do
bgneal@4 91 ================
bgneal@4 92
bgneal@4 93 Django 1.5's largest new feature is probably its support for a `configurable
bgneal@4 94 User model`_. This impacts my largest site, and I wasn't quite sure how to
bgneal@4 95 proceed on this front. This is the only issue I feel like Django threw me under
bgneal@4 96 the bus on. Fortunately, the ``get_profile()`` and ``AUTH_PROFILE_MODULE``
bgneal@4 97 stuff will not be removed until Django 1.7. In addition, the author of the
bgneal@4 98 South_ library is developing model migration support which will also land in
bgneal@4 99 Django 1.7. Thus there is some time to sort this out, and I'm hoping Django
bgneal@4 100 will have some tutorials or docs on how to migrate away from the old
bgneal@4 101 ``AUTH_PROFILE_MODULE`` scheme.
bgneal@4 102
bgneal@4 103 Conclusion
bgneal@4 104 ==========
bgneal@4 105
bgneal@4 106 The upgrade process went smoother and quicker than I thought thanks to the
bgneal@4 107 excellent release notes and the Django team's use of Python warnings to flag
bgneal@4 108 deprecated features.
bgneal@4 109
bgneal@4 110
bgneal@4 111 .. _Django: https://www.djangoproject.com/
bgneal@4 112 .. _release notes: https://docs.djangoproject.com/en/1.5/releases/1.5/
bgneal@4 113 .. _deprecation timeline: https://docs.djangoproject.com/en/1.5/internals/deprecation/
bgneal@4 114 .. _warnings: http://docs.python.org/library/warnings.html
bgneal@4 115 .. _pdb: http://docs.python.org/library/pdb.html
bgneal@4 116 .. _Celery: http://www.celeryproject.org/
bgneal@4 117 .. _pip: http://www.pip-installer.org/en/latest/
bgneal@4 118 .. _django-localflavor: https://pypi.python.org/pypi/django-localflavor
bgneal@4 119 .. _configurable user model: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user
bgneal@4 120 .. _South: http://south.aeracode.org/