Django 1.0 在某些地方与 0.96 版本是不兼容的。
\n这个指南会帮助你把 0.96 的项目和应用移植到 1.0 版本。本文档的第一部分包含了需要运行在 1.0上的常见变更。如果通过了第一部分的变更，你的代码依然无法运行，那么请检查 Less-common Changes 不常见的变更部分中列出的兼容问题。
\n\n本部分描述了 0.96 与 1.0 之间的变更，这些变更都是大部分用户会做的事情。
\n逐字地把字符串 ('foo') 变成 Unicode 字符串 (u'foo')。Django 目前从始至终贯穿地使用 Unicode 字符集字符串。在绝大多数地方，生食字符串会继续有效，但更新成 Unicode 字符串会防止某些含糊的问题出现。
查阅 Unicode 数据 文档了解细节。
\n对于你的模型文件中常见的变更：
\nmaxlength 重命名为 max_lengthLink to this heading#把你的 maxlength 参数名变成 max_length (这次参数名的变更是为了与表单区域保持一致)：
__unicode__ 代替 __str__Link to this heading#使用 __unicode__ 方法替换你的模型中的 __str__ 函数，然后才能确保你使用 使用 Unicode 字符集 (u'foo') 中所介绍的方法。
prepopulated_fromLink to this heading#删除模型区域中 prepopulated_from 参数。这个参数不再合法，而且已经转移到管理员 admin.py 模块里的 ModelAdmin 类中去了。查阅 `管理员`_内容了解更多对管理员变更的细节。
coreLink to this heading#删除你的模型区域里的 core 参数。这个参数不再需要了，因为相同功能 (参考 行内编辑) 目前已经由后台接口做出不同地处理。你不用再担心行内编辑，除非你在 管理员 部分才考虑行内编辑。目前，删除所有对 core 参数的指向。
admin.py 替换 class Admin:Link to this heading#从你的模型里移除所有嵌入 class Admin 管理员类声明。如果你保留这种类的话，不会对任何有影响，但也不会起任何作用。要注册应用程序管理员，你要把这种类的声明移到 admin.py 管理员模块文件里；查看 管理员 内容了解更多细节。
下面的一个例子 models.py 模型文件含有所有你需要做出的变更：
老版本 (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)\n新版本 (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 u'%s %s' % (self.first_name, self.last_name)\n新版本 (1.0) ``admin.py``管理员模块:
\nfrom django.contrib import admin\nfrom models import Author\n\nclass AuthorAdmin(admin.ModelAdmin):\n list_display = ['first_name', 'last_name']\n prepopulated_fields = {\n 'slug': ('first_name', 'last_name')\n }\n\nadmin.site.register(Author, AuthorAdmin)\n在 1.0 版本中最具挑战性的新管理员功能问题之一。Django 管理接口 (django.contrib.admin) 管理员功能已经完全重构了；许多管理员定义目前都完全从许多模型定义中解构出来，许多框架都重写后使用 Django 的新表单处理库，而且重新设计成具有扩展和自定义能力。
实际中，意味着你要重写所有你的 class Admin 管理员类声明。你已经在上面的 models 中见过了如何替换你的 class Admin 管理员类，就是在 admin.py 管理员模块文件中用一个 admin.site.register() 管理员网页注册调用来替代。下面这些都是一些更详细的如何重写 Admin 管理员声明类的新句法。
新的 edit_inline 行内编辑选项都已经移到 admin.py 管理员模块中了。下面有一个例子：
老版本 (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)\n新版本 (1.0):
\nclass ChildInline(admin.StackedInline):\n model = Child\n extra = 3\n\nclass ParentAdmin(admin.ModelAdmin):\n model = Parent\n inlines = [ChildInline]\n\nadmin.site.register(Parent, ParentAdmin)\n查阅 InlineModelAdmin 对象 管理员行内文档了解更多细节。
\nfields，或使用 fieldsetsLink to this heading#老的 fields 句法是非常迷糊的，而且已经被简化过。老的句法依然有效，但你要使用 fieldsets 来代替老旧句法。
老版本 (0.96):
\nclass ModelOne(models.Model):\n ...\n\n class Admin:\n fields = (\n (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 )\n新版本 (1.0):
\nclass ModelOneAdmin(admin.ModelAdmin):\n fields = ('foo', 'bar')\n\nclass ModelTwoAdmin(admin.ModelAdmin):\n fieldsets = (\n ('group1', {'fields': ('foo','bar'), 'classes': 'collapse'}),\n ('group2', {'fields': ('spam','eggs'), 'classes': 'collapse wide'}),\n )\nurls.py 模块Link to this heading#如果你正在使用后台界面，你需要更新你的根路径``urls.py`` 模块。
\n老版本 (0.96) urls.py:
from django.conf.urls.defaults import *\n\nurlpatterns = patterns('',\n (r'^admin/', include('django.contrib.admin.urls')),\n\n # ... the rest of your URLs here ...\n)\n新版本 (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\nadmin.autodiscover()\n\nurlpatterns = patterns('',\n (r'^admin/(.*)', admin.site.root),\n\n # ... the rest of your URLs here ...\n)\ndjango.forms 来代替 newforms 用法Link to this heading#用 django.forms 来替换 django.newforms 用法 -- Django 1.0 版本重命名了 newforms 模块名 (曾用在 0.96 版本的名字) 采用以前用过的 forms 名字。而 oldforms 模块也会被移除。
如果你已经使用 newforms 库的话，而且你采用了我们所建议的 import 导入语句句法，那么所有你要做的就是改变一下你的导入依据即可。
老版本:
\nfrom django import newforms as forms\n新版本:
\nfrom django import forms\n如果你正在使用老的表单系统 (正规的名字是 django.forms 和 django.oldforms)，那么你要重写你的表单。良好地开始就是从阅读 表单文档 内容
代替上传文件的用法 -- 那就是，采用 request.FILES 文件请求入口 -- 与含有 UploadedFile 文件上传类的简单字典一样。老的字典句法不再有效了。
因此，看起来就像:
\ndef my_view(request):\n f = request.FILES['file_field_name']\n ...\n...你需要做出如下变更：
\n老版本 (0.96) | \n新版本 (1.0) | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
class:django.db.models.FileField 的内部实现已更改。一个明显的结果是您访问特殊属性(URL, filename, image size, 等等)的方式发生了变化。您需要进行以下更改，假设您的模型: class:~django.db.models.FileField 调用``myfile``:
\n老版本 (0.96) | \n新版本 (1.0) | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
请注意``width``和``height``属性仅对: class:~django.db.models.ImageField 字段有意义。更多详细信息可以在: doc:model API</ref/models/fields> documentation 文档中找到。
\nPaginator 而不是 ObjectPaginatorLink to this heading#0.96版本中的``ObjectPaginator`` 已被删除，并替换为一个改进版本: class:django.core.paginator.Paginator。
\n默认情况下，模板系统现在会自动对每个变量的输出进行HTML转义。要了解更多信息，请参阅 自动 HTML 转义。
\n要禁用单个变量的自动转义，请使用:tfilter:safe filter:
\nThis will be escaped: {{ data }}\nThis will not be escaped: {{ data|safe }}\n要禁用整个模板的自动转义，请将模板（或模板的特定部分）包装在:ttag:autoescape tag:
\n{% autoescape off %}\n ... unescaped template content here ...\n{% endautoescape %}\n以下更改是较小的、更本地化的更改。它们应该只影响更高级的用户，但是通读列表并检查代码中的这些东西可能是值得的。
\n将``**kwargs``添加到任何注册的信号处理程序中。
通过:class:`~django.dispatch.Signal`对象上的方法连接、断开连接和发送信号，而不是通过``django.dispatch.dispatcher``中的模块方法。
Remove any use of the Anonymous and Any sender options; they no longer\nexist. 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:
\n老版本 (0.96) | \n新版本 (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:
老版本 (0.96):
\ntry:\n Model.objects.get(...)\nexcept AssertionError:\n handle_the_error()\n新版本 (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 datetime.datetime.now:
老版本 (0.96):
\nclass Article(models.Model):\n title = models.CharField(maxlength=100)\n published = models.DateField(default=LazyDate())\n新版本 (1.0):
\nimport datetime\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#老版本 (0.96):
\nclass MyModel(models.Model):\n field_name = models.FloatField(max_digits=10, decimal_places=3)\n ...\n新版本 (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\n注意：
\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 response.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#老版本 (0.96):
\nfrom django.test import Client\nc = Client()\nc.login('/path/to/login','myuser','mypassword')\n新版本 (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\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\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:
老版本 (0.96) | \n新版本 (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