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 został przeniesionyLink to this heading#Stała LOGIN_URL została przeniesiona z django.contrib.auth do modułu settings. Zamiast używać from django.contrib.auth import LOGIN_URL, odwołaj się do settings.LOGIN_URL.
APPEND_SLASH zostało zaktualizowaneLink 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.
Dla większości osób, ta zmiana nie będzie wymagała wprowadzenia żadnych zmian. Jeśli jednak posiadasz patterny URL wyglądające tak jak ten:
\nr"/some_prefix/(.*)$"\nPoprzednio te patterny zostałyby przekierowane tak, aby zawierały końcowy ukośnik. Jeśli chcesz zawsze posiadać ukośnik na takich URL-ach, przepisz pattern na:
\nr"/some_prefix/(.*/)$"\nget()Link to this heading#Manager-y od teraz zwracają wyjątek MultipleObjectsReturned zamiast 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 został zwolnionyLink to this heading#Klasa pomocnicza LazyDate już nie istnieje.
Domyślne wartości pól i argumentów query mogą być także obiektami wywoływalnymi, dlatego instancje LazyDate mogą być zamienione na referencję do datetime.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, a FloatField jest od teraz poprawnym float-em.Link 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 ...\nJeśli zapomnisz dokonać tej zmiany, zobaczysz błędu mówiące, że FloatField nie przyjmuje atrybutu max_digits w __init__, gdyż nowy FloatField nie przyjmuje argumentów dotyczących jego precyzji.
Jeśli używasz MySQL albo PostgreSQL, żadne dodatkowe zmiany nie są wymagane. Typy kolumn bazy danych dla DecimalField są takie same jak dla starego FloatField.
Jeśli używasz SQLite, musisz wymusić na bazie danych traktowanie niektórych kolumn jako typ decimal zamiast jako float. Aby to zrobić, będziesz musiał ponownie wczytać swoje dane. Zrób to dopiero po tym jak zaktualizujesz kod Django i zmienisz typ pól na DecimalField.
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\nNotatki:
\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.
HTTPResponseLink to this heading#Nazwa django.http.HttpResponse.headers została zmieniona na _headers a HttpResponse obsługuje od teraz bezpośrednie sprawdzanie występowania kluczy. Używaj więc if header in response: zamiast if header in response.headers:.
Klasy relacji generycznych – GenericForeignKey i GenericRelation – zostały przeniesione do modułu django.contrib.contenttypes.
django.test.Client.login() został zmienionyLink 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 został znacznie zrefaktorowany.
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