Recently, in my work we needed to upgrade one of our tools, written in Python2.6 and Django 1.2.3. Initially thought of directly upgrading to Django 1.6 but we wanted (1) a smooth migration and (2) provide backwards compatibility with 1.2. Migration seemed too cumbersome: it is mandatory to change paths for many generic views and not every functionality seems to be achievable (e.g. the get_model_and_form_class method from the create_update view).

Note that these generic views are already introduce in 1.4, but its use is not enforced. Similarly, there are many other modifications (see Django 1.4 release notes) that are introduced in this version but its use is not enforced.

Below there are some points you must address in order to perform migration. Also note that I speak only from my experience — therefore this is a only subset of required modifications needed for your app to work. Think of this as a guide for a quick migration. However, if you have enough time to experiment, my advice is that you go for a full migration. This way you’ll pave the road for further upgrades.

Part 1: the new settings

DATABASES structure

In our case, we provide settings files to be modified by the user. The DATABASES structure should be added into your app’s static settings, far away from any potential modification from the user’s side. In any case, the user is not interested in this structure, right?

Part 2: the modified settings


Both the package and module name for the template loaders is changed in Django 1.4.5.

Part 3: the modified fields


This field, once present in Django 1.2.3, is no longer supported. It must be changed to a TextField to work under Django 1.4.5. This field already existed under Django, therefore this change shall not affect your app, whether it runs under 1.2.3 or 1.4.5.

This post may be updated in the future if I find more hard requirements.

Share on FacebookTweet about this on TwitterShare on Google+Share on RedditEmail this to someonePrint this page
Rate the usefulness:
(No Ratings Yet)