Upgrading from Django 1.4 to Django 1.7

Normally when I make a major change to our backend, I Google the process to see what roadblocks other people have encountered. This saves me time because I know in advance what need to be done. For our recent move from Django 1.4 to Django 1.7 I found nothing. This meant I had to learn a few things about upgrading Django the hard way.

Here are the minimum things you need to know, to migrate from Django 1.4 to 1.7:

1. Adding a SECRET_KEY to your settings.py

Changed in Django 1.5, Django now requires every project to have a SECRET_KEY. It will refuse to start without a key. The key is used to provide cryptographic signing, and should be set to a unique value.

I used the following website to generate a secret key:

http://www.miniwebtool.com/django-secret-key-generator/

2. The concept of  Applications and applications registry in 1.7:

This is a new concept introduced in 1.7 where Django maintains a registry of your installed applications, hence making it really easy to manage and introspect all your apps. The best part I liked about this feature is that it makes it super easy to manage subapps and also run initialization code when each app is ready.

You can learn more about this here: https://docs.djangoproject.com/en/1.7/ref/applications/

You must keep in mind that because of this, you can no longer import models in your __init__.py files anymore, since it will break. But this in turn forces you to use the ready() function that you can override in your custom AppConfig in order to import all your models and hence given a consistent way of running init code across all Django projects.

3. Upgrading Django template url tags to use new syntax introduced in Django 1.5:

If you were already using Django’s  , you can skip this step, but in case you weren’t you must now change your url tags from to .

There is this awesome sed command that you can use to convert all your url tags to the new format. You can either run this command from your template directory

sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g" * {% url ‘1’#g” *
or in order to run it recursively you can run the following:
find . -type f -print0 | xargs -0 sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g"

Credit goes to Enrico for posting this shortcut on stack here.

4. App Labels

While migrating from Django 1.4 I had issues where the new django migrations (which is the next topic) had issues recognizing which ‘app’ a given model belonged to. As a rule of thumb, I would just add app_label to all the models Meta class and set it to the package (folder) name.

5. Migrations

With Django 1.7 you no longer need south, since migrations are now built-in. The best way to migrate from south to django migrations is to delete all the migration files from your migrations folder (leave the __init__.py in there).

Run the following to generate all the new migrations:

python manage.py makemigrations

followed by migrate (if django sees that the table already exists then it won’t run those migrations)

python manage.py migrate

5. Urls.py

You might have the following in all your urls.py

from django.conf.urls.defaults import patterns, include, url

You will want to replace that with:

from django.conf.urls import patterns, include, url

6. HttpResponse

If there is any code that sets the mimetype of the HttpResponse manually you will need to change it to content_type.

HttpResponse({"message": "hello world!"}, mimetype="application/json")

becomes

HttpResponse({"message": "hello world!"}, content_type="application/json")

7. get_query_set

Also the get_query_set method has been deprecated in preference for get_queryset

So you will need to change that as well if you were overriding the get_query_set method previously.

8. Caching

If you were using ORM caching like johnny-cache, you will need to either kill that, roll your own or upgrade to something like django-cachalot.

9. Plugins

Remember to upgrade all your requirements and plugins. A lot of the older plugins might not be compatible with Django 1.7 or they might have released a newer version that is 1.7 compatible.

10. Celery

It would be a good idea to upgrade to Celery >= 3.1.16 as well, which has some setting changes as well, that you will need to handle.

It feels good to be back on the latest version and able to use the latest features and plugins.