[Django]-Upgrading from Django 1.4 to Django 1.7 – will it work?

by

4👍

✅

You can have whatever project structure you desire in Django. So you will be able to run your project barring any other upgrading issues. One of the best current examples of project structure is the Django Cookiecutter by PyDanny.

Besides abstract user classes, authentication, and migrations ( and the commands like syncdb / schemamigration that go with it) nothing should really stand in your way to upgrade. Some things have been depreciated but they’re well documented and easy to fix. In each release, they’ve ensured the upgrade path and backwards compatibility is clear and as good as possible.

I’d recommend following the best practices with 1.5, 1.6, and 1.7 that have changed the way the community writes Django applications. My favorite resource for to learn about them is Two Scoops of Django. PyDanny is one of the authors. There are two versions, for 1.5 and 1.6, and each goes over the major differences between the previous version and how the new features have changed the way you should write Django apps. By reading both you could get a clear view of how to upgrade your app from 1.4 to 1.5 to 1.6. Beyond that, the release notes of each version, and the django-cookiecutter are great places to see whats changed and what the new best practices are.

👤agconti

3👍

I want to be clear that this is a distilled version of the answers found at the link provided by harshil above. I am adding it here in case the URL breaks in the future as it helped me.

  1. ADD A SECRET_KEY TO YOUR SETTINGS.PY

Changed in Django 1.5, Django now requires every project to have a SECRET_KEY.

  1. 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/

  1. UPGRADING DJANGO TEMPLATE URL TAGS TO USE NEW SYNTAX INTRODUCED IN DJANGO 1.5:

If you were already using Django’s {% load url from future %}, you can skip this step, but in case you weren’t you must now change your url tags from {% url view_name args %} to {% url 'view_name' args %}.

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" *

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.

  1. 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.

  1. 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

  1. 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

  1. 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")

  1. GET_QUERY_SET

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.

  1. 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.

  1. PLUGINS:

Remember to upgrade all your requirements and plugins. A lot of the older plugins might not be compatible with Django 1.7.

  1. Upgrade to Celery >= 3.1.16
👤nu everest

0👍

Here is a good list of things to keep in mind when upgrading from 1.4 http://labs.seedinvest.com/backend/upgrading-from-django-1-4-to-django-1-7/

👤harshil

0👍

this article suggest the best way to do it, is one version step at a time:

This section will make it clear that you should only ever upgrade one release at a time. You should not upgrade from 1.4 to 1.7 directly. Instead, make the jump from 1.4 to 1.5 first, then proceed to 1.6, and so on. This is in keeping with the idea of taking small steps.

see:

http://andrewsforge.com/article/upgrading-django-to-17/part-4-upgrade-strategies/

However, it probably depend on the time a project can be ‘on hold’ during refactoring it to a newer version probably mean the progress of new features and so on has to be ‘on hold’.
I guess doing it all at once, is a big step, so a lot of work at once, but dividing it in small steps (version by version) means shorter tracks, but the overall track will probably be longer.

👤michel.iamit

Leave a comment