Django 1.0 breaks compatibility with 0.96 in some areas.
\nThis guide will help you port 0.96 projects and apps to 1.0. The first part of\nthis document includes the common changes needed to run with 1.0. If after\ngoing through the first part your code still breaks, check the section\nLess-common Changes for a list of a bunch of less-common compatibility\nissues.
\n\nThis section describes the changes between 0.96 and 1.0 that most users will\nneed to make.
\nChange string literals ('foo') into Unicode literals (u'foo'). Django\nnow uses Unicode strings throughout. In most places, raw strings will continue\nto work, but updating to use Unicode literals will prevent some obscure\nproblems.
See Unicode data for full details.
\nCommon changes to your models file:
\nmaxlength to max_lengthLink to this heading#Rename your maxlength argument to max_length (this was changed to be\nconsistent with form fields):
__str__ with __unicode__Link to this heading#Replace your model’s __str__ function with a __unicode__ method, and\nmake sure you use Unicode (u'foo') in that method.
prepopulated_fromLink to this heading#Remove the prepopulated_from argument on model fields. It’s no longer valid\nand has been moved to the ModelAdmin class in admin.py. See the\nadmin, below, for more details about changes to the admin.
coreLink to this heading#Remove the core argument from your model fields. It is no longer\nnecessary, since the equivalent functionality (part of inline editing) is handled differently by the admin interface now. You don’t\nhave to worry about inline editing until you get to the admin section,\nbelow. For now, remove all references to core.
class Admin: with admin.pyLink to this heading#Remove all your inner class Admin declarations from your models. They won’t\nbreak anything if you leave them, but they also won’t do anything. To register\napps with the admin you’ll move those declarations to an admin.py file;\nsee the admin below for more details.
Below is an example models.py file with all the changes you’ll need to\nmake:
Old (0.96) models.py:
class Author(models.Model):\n first_name = models.CharField(maxlength=30)\n last_name = models.CharField(maxlength=30)\n slug = models.CharField(maxlength=60, prepopulate_from=("first_name", "last_name"))\n\n class Admin:\n list_display = ["first_name", "last_name"]\n\n def __str__(self):\n return "%s %s" % (self.first_name, self.last_name)\nNew (1.0) models.py:
class Author(models.Model):\n first_name = models.CharField(max_length=30)\n last_name = models.CharField(max_length=30)\n slug = models.CharField(max_length=60)\n\n def __unicode__(self):\n return "%s %s" % (self.first_name, self.last_name)\nNew (1.0) admin.py:
from django.contrib import admin\nfrom models import Author\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name"]\n prepopulated_fields = {"slug": ("first_name", "last_name")}\n\n\nadmin.site.register(Author, AuthorAdmin)\nOne of the biggest changes in 1.0 is the new admin. The Django administrative\ninterface (django.contrib.admin) has been completely refactored; admin\ndefinitions are now completely decoupled from model definitions, the framework\nhas been rewritten to use Django’s new form-handling library and redesigned\nwith extensibility and customization in mind.
Practically, this means you’ll need to rewrite all of your class Admin\ndeclarations. You’ve already seen in models above how to replace your\nclass Admin with an admin.site.register() call in an admin.py file.\nBelow are some more details on how to rewrite that Admin declaration into\nthe new syntax.
The new edit_inline options have all been moved to admin.py. Here’s an\nexample:
Old (0.96):
\nclass Parent(models.Model): ...\n\n\nclass Child(models.Model):\n parent = models.ForeignKey(Parent, edit_inline=models.STACKED, num_in_admin=3)\nNew (1.0):
\nclass ChildInline(admin.StackedInline):\n model = Child\n extra = 3\n\n\nclass ParentAdmin(admin.ModelAdmin):\n model = Parent\n inlines = [ChildInline]\n\n\nadmin.site.register(Parent, ParentAdmin)\nSee InlineModelAdmin objects for more details.
\nfields, or use fieldsetsLink to this heading#The old fields syntax was quite confusing, and has been simplified. The old\nsyntax still works, but you’ll need to use fieldsets instead.
Old (0.96):
\nclass ModelOne(models.Model):\n ...\n\n class Admin:\n fields = ((None, {"fields": ("foo", "bar")}),)\n\n\nclass ModelTwo(models.Model):\n ...\n\n class Admin:\n fields = (\n ("group1", {"fields": ("foo", "bar"), "classes": "collapse"}),\n ("group2", {"fields": ("spam", "eggs"), "classes": "collapse wide"}),\n )\nNew (1.0):
\nclass ModelOneAdmin(admin.ModelAdmin):\n fields = ("foo", "bar")\n\n\nclass ModelTwoAdmin(admin.ModelAdmin):\n fieldsets = (\n ("group1", {"fields": ("foo", "bar"), "classes": "collapse"}),\n ("group2", {"fields": ("spam", "eggs"), "classes": "collapse wide"}),\n )\nurls.pyLink to this heading#If you’re using the admin site, you need to update your root urls.py.
Old (0.96) urls.py:
from django.conf.urls.defaults import *\n\nurlpatterns = patterns(\n "",\n (r"^admin/", include("django.contrib.admin.urls")),\n # ... the rest of your URLs here ...\n)\nNew (1.0) urls.py:
from django.conf.urls.defaults import *\n\n# The next two lines enable the admin and load each admin.py file:\nfrom django.contrib import admin\n\nadmin.autodiscover()\n\nurlpatterns = patterns(\n "",\n (r"^admin/(.*)", admin.site.root),\n # ... the rest of your URLs here ...\n)\ndjango.forms instead of newformsLink to this heading#Replace django.newforms with django.forms – Django 1.0 renamed the\nnewforms module (introduced in 0.96) to plain old forms. The\noldforms module was also removed.
If you’re already using the newforms library, and you used our recommended\nimport statement syntax, all you have to do is change your import\nstatements.
Old:
\nfrom django import newforms as forms\nNew:
\nfrom django import forms\nIf you’re using the old forms system (formerly known as django.forms and\ndjango.oldforms), you’ll have to rewrite your forms. A good place to start\nis the forms documentation
Replace use of uploaded files – that is, entries in request.FILES – as\nsimple dictionaries with the new\nUploadedFile. The old dictionary\nsyntax no longer works.
Thus, in a view like:
\ndef my_view(request):\n f = request.FILES["file_field_name"]\n ...\n…you’d need to make the following changes:
\nOld (0.96) | \nNew (1.0) | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
The internal implementation of django.db.models.FileField have\nchanged. A visible result of this is that the way you access special attributes\n(URL, filename, image size, etc.) of these model fields has changed. You will\nneed to make the following changes, assuming your model’s\nFileField is called myfile:
Old (0.96) | \nNew (1.0) | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
Note that the width and height attributes only make sense for\nImageField fields. More details can be found in the\nmodel API documentation.
Paginator instead of ObjectPaginatorLink to this heading#The ObjectPaginator in 0.96 has been removed and replaced with an improved\nversion, django.core.paginator.Paginator.
By default, the template system now automatically HTML-escapes the output of\nevery variable. To learn more, see Automatic HTML escaping.
\nTo disable auto-escaping for an individual variable, use the safe\nfilter:
This will be escaped: {{ data }}\nThis will not be escaped: {{ data|safe }}\nTo disable auto-escaping for an entire template, wrap the template (or just a\nparticular section of the template) in the autoescape tag:
{% autoescape off %}\n ... unescaped template content here ...\n{% endautoescape %}\nThe following changes are smaller, more localized changes. They should only\naffect more advanced users, but it’s probably worth reading through the list\nand checking your code for these things.
\nAdd **kwargs to any registered signal handlers.
Connect, disconnect, and send signals via methods on the\nSignal object instead of through module methods in\ndjango.dispatch.dispatcher.
Remove any use of the Anonymous and Any sender options; they no\nlonger exist. You can still receive signals sent by any sender by using\nsender=None
Make any custom signals you’ve declared into instances of\ndjango.dispatch.Signal instead of anonymous objects.
Here’s quick summary of the code changes you’ll need to make:
\nOld (0.96) | \nNew (1.0) | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
If you were using Django 0.96’s django.contrib.comments app, you’ll need to\nupgrade to the new comments app introduced in 1.0. See the upgrade guide\nfor details.
django.contrib.localflavor.usa has been renamed to\ndjango.contrib.localflavor.us. This change was made to match the naming\nscheme of other local flavors. To migrate your code, all you need to do is\nchange the imports.
SessionBase.get_new_session_key() has been renamed to\n_get_new_session_key(). get_new_session_object() no longer exists.
save()Link to this heading#Previously, loading a row automatically ran the model’s save() method. This\nis no longer the case, so any fields (for example: timestamps) that were\nauto-populated by a save() now need explicit values in any fixture.
The old EnvironmentError has split into an\nImportError when Django fails to find the settings module\nand a RuntimeError when you try to reconfigure settings\nafter having already used them.
LOGIN_URL has movedLink to this heading#The LOGIN_URL constant moved from django.contrib.auth into the\nsettings module. Instead of using from django.contrib.auth import\nLOGIN_URL refer to settings.LOGIN_URL.
APPEND_SLASH behavior has been updatedLink to this heading#In 0.96, if a URL didn’t end in a slash or have a period in the final\ncomponent of its path, and APPEND_SLASH was True, Django would\nredirect to the same URL, but with a slash appended to the end. Now, Django\nchecks to see whether the pattern without the trailing slash would be matched\nby something in your URL patterns. If so, no redirection takes place, because\nit is assumed you deliberately wanted to catch that pattern.
For most people, this won’t require any changes. Some people, though, have URL\npatterns that look like this:
\nr"/some_prefix/(.*)$"\nPreviously, those patterns would have been redirected to have a trailing\nslash. If you always want a slash on such URLs, rewrite the pattern as:
\nr"/some_prefix/(.*/)$"\nget()Link to this heading#Managers now return a MultipleObjectsReturned\nexception instead of AssertionError:
Old (0.96):
\ntry:\n Model.objects.get(...)\nexcept AssertionError:\n handle_the_error()\nNew (1.0):
\ntry:\n Model.objects.get(...)\nexcept Model.MultipleObjectsReturned:\n handle_the_error()\nLazyDate has been firedLink to this heading#The LazyDate helper class no longer exists.
Default field values and query arguments can both be callable objects, so\ninstances of LazyDate can be replaced with a reference to\ndatetime.datetime.now:
Old (0.96):
\nclass Article(models.Model):\n title = models.CharField(maxlength=100)\n published = models.DateField(default=LazyDate())\nNew (1.0):
\nimport datetime\n\n\nclass Article(models.Model):\n title = models.CharField(max_length=100)\n published = models.DateField(default=datetime.datetime.now)\nDecimalField is new, and FloatField is now a proper floatLink to this heading#Old (0.96):
\nclass MyModel(models.Model):\n field_name = models.FloatField(max_digits=10, decimal_places=3)\n ...\nNew (1.0):
\nclass MyModel(models.Model):\n field_name = models.DecimalField(max_digits=10, decimal_places=3)\n ...\nIf you forget to make this change, you will see errors about FloatField\nnot taking a max_digits attribute in __init__, because the new\nFloatField takes no precision-related arguments.
If you’re using MySQL or PostgreSQL, no further changes are needed. The\ndatabase column types for DecimalField are the same as for the old\nFloatField.
If you’re using SQLite, you need to force the database to view the\nappropriate columns as decimal types, rather than floats. To do this, you’ll\nneed to reload your data. Do this after you have made the change to using\nDecimalField in your code and updated the Django code.
To upgrade each application to use a DecimalField, you can do the\nfollowing, replacing <app> in the code below with each app’s name:
$ ./manage.py dumpdata --format=xml <app> > data-dump.xml\n$ ./manage.py reset <app>\n$ ./manage.py loaddata data-dump.xml\nNotes:
\nIt’s important that you remember to use XML format in the first step of\nthis process. We are exploiting a feature of the XML data dumps that makes\nporting floats to decimals with SQLite possible.
In the second step you will be asked to confirm that you are prepared to\nlose the data for the application(s) in question. Say yes; we’ll restore\nthis data in the third step.
DecimalField is not used in any of the apps shipped with Django prior\nto this change being made, so you do not need to worry about performing\nthis procedure for any of the standard Django models.
If something goes wrong in the above process, just copy your backed up\ndatabase file over the original file and start again.
\ndjango.views.i18n.set_language() now requires a POST requestLink to this heading#Previously, a GET request was used. The old behavior meant that state (the\nlocale used to display the site) could be changed by a GET request, which is\nagainst the HTTP specification’s recommendations. Code calling this view must\nensure that a POST request is now made, instead of a GET. This means you can\nno longer use a link to access the view, but must use a form submission of\nsome kind (e.g. a button).
\n_() is no longer in builtinsLink to this heading#_() (the callable object whose name is a single underscore) is no longer\nmonkeypatched into builtins – that is, it’s no longer available magically in\nevery module.
If you were previously relying on _() always being present, you should now\nexplicitly import ugettext or ugettext_lazy, if appropriate, and alias\nit to _ yourself:
from django.utils.translation import ugettext as _\nHttpRequestLink to this heading#HttpRequest objects no longer directly support dictionary-style\naccess; previously, both GET and POST data were directly\navailable on the HttpRequest object (e.g., you could check for a\npiece of form data by using if 'some_form_key' in request or by\nreading request['some_form_key']. This is no longer supported; if\nyou need access to the combined GET and POST data, use\nrequest.REQUEST instead.
It is strongly suggested, however, that you always explicitly look in\nthe appropriate dictionary for the type of request you expect to\nreceive (request.GET or request.POST); relying on the combined\nrequest.REQUEST dictionary can mask the origin of incoming data.
HTTPResponse headersLink to this heading#django.http.HttpResponse.headers has been renamed to _headers and\nHttpResponse now supports containment checking directly.\nSo use if header in response: instead of if header in\nresponse.headers:.
The generic relation classes – GenericForeignKey and GenericRelation\n– have moved into the django.contrib.contenttypes module.
django.test.Client.login() has changedLink to this heading#Old (0.96):
\nfrom django.test import Client\n\nc = Client()\nc.login("/path/to/login", "myuser", "mypassword")\nNew (1.0):
\n# ... same as above, but then:\nc.login(username="myuser", password="mypassword")\ndjango.core.management has been greatly refactored.
Calls to management services in your code now need to use\ncall_command. For example, if you have some test code that calls flush and\nload_data:
from django.core import management\n\nmanagement.flush(verbosity=0, interactive=False)\nmanagement.load_data(["test_data"], verbosity=0)\n…you’ll need to change this code to read:
\nfrom django.core import management\n\nmanagement.call_command("flush", verbosity=0, interactive=False)\nmanagement.call_command("loaddata", "test_data", verbosity=0)\ndjango-admin.py and manage.py now require subcommands to precede\noptions. So:
$ django-admin.py --settings=foo.bar runserver\n…no longer works and should be changed to:
\n$ django-admin.py runserver --settings=foo.bar\nSortedDictFromList is goneLink to this heading#django.newforms.forms.SortedDictFromList was removed.\ndjango.utils.datastructures.SortedDict can now be instantiated with\na sequence of tuples.
To update your code:
\nUse django.utils.datastructures.SortedDict wherever you were\nusing django.newforms.forms.SortedDictFromList.
Because django.utils.datastructures.SortedDict.copy doesn’t\nreturn a deepcopy as SortedDictFromList.copy() did, you will need\nto update your code if you were relying on a deepcopy. Do this by using\ncopy.deepcopy directly.
Almost all of the database backend-level functions have been renamed and/or\nrelocated. None of these were documented, but you’ll need to change your code\nif you’re using any of these functions, all of which are in django.db:
Old (0.96) | \nNew (1.0) | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n