2012年3月23日
欢迎来到Django 1.4！
这些发行说明涵盖了 new features 以及一些 backwards incompatible changes 从django 1.3或更旧版本升级时，您需要注意。我们还删除了一些功能，这些功能在 our deprecation plan 我们已经 begun the deprecation process for some features .
Django1.4中最大的新功能是 support for time zones 处理日期/时间时。启用后，此django将以UTC格式存储日期/时间，在内部使用时区感知对象，并将其转换为用户的本地时区进行显示。
如果要将现有项目升级到django 1.4，切换到时区感知模式可能需要注意：新模式不允许某些以前被接受的相当草率的行为。我们鼓励任何正在升级的人查看 timezone migration guide 以及 timezone FAQ 对于有用的指针。
Django 1.4的其他显著新功能包括：
许多ORM改进，包括 SELECT FOR UPDATE support 有能力 bulk insert 大型数据集可提高性能，以及 QuerySet.prefetch_related ，一种在以下区域批量加载相关对象的方法： select_related() 不起作用。
一些不错的安全措施，包括 improved password hashing （特写） PBKDF2 和 bcrypt 支持，新的 tools for cryptographic signing 几个 CSRF improvements 和 simple clickjacking protection .
安 updated default project layout and manage.py 这消除了先前版本的“魔力”。对于那些不喜欢新布局的人，您可以使用 custom project and app templates 相反！
…还有更多； see below 你说什么？
在可能的情况下，我们尝试以向后兼容的方式根据 our API stability policy 政策。但是，与以前的版本一样，Django1.4附带了一些小版本 backwards incompatible changes ；从Django的早期版本升级的用户应该仔细阅读该列表。
Django1.4已经放弃了对python 2.4的支持。python 2.5现在是所需的最低python版本。Django在python 2.5、2.6和2.7上进行测试和支持。
此更改只会影响少数Django用户，因为目前大多数操作系统供应商都将python 2.5或更新版本作为其默认版本。但是，如果您仍在使用python 2.4，则需要坚持使用django 1.3，直到可以升级为止。每 our support policy ，django 1.3将继续获得安全支持，直到django 1.5发布。
Django目前不支持Python3.x。在django 1.4发布之前的某个时候，我们计划发布一个文档，概述我们的完整时间线，以取消对python 2.x的预测并转到python 3.x。
在以前的版本中，Django使用了“幼稚”的日期/时间（即没有关联时区的日期/时间），让每个开发人员来解释给定的日期/时间“真正意味着什么”。这会导致各种与时区相关的微妙错误。
在django 1.4中，您现在可以将django切换到更正确的时区感知模式。在此模式下，Django将日期和时间信息以UTC格式存储在数据库中，在内部使用时区感知的日期时间对象，并将其转换为模板和表单中的最终用户时区。使用此功能的原因包括：
为世界各地的用户定制日期和时间显示。
为数据库的可移植性和互操作性以UTC格式存储日期时间。（此参数不适用于PostgreSQL，因为它已经在django 1.3中存储了带有时区信息的时间戳。）
避免围绕DST转换出现数据损坏问题。
默认情况下，在使用创建的新项目中启用时区支持 startproject . 如果要在现有项目中使用此功能，请阅读 migration guide . 如果你遇到问题，会有帮助的 FAQ .
Django1.4支持与浏览器内测试框架（如 Selenium. 新的 django.test.LiveServerTestCase 基类允许您更全面地测试站点前端和后端之间的交互。见 documentation 更多细节和具体例子。
manage.py¶Django 1.4提供更新的默认项目布局和 manage.py 文件为 startproject 管理命令。这些解决了以前的一些问题 manage.py 处理导致双重导入的python导入路径、从开发到部署的问题以及其他难以调试的路径问题。
以前的 manage.py 调用了现在已弃用的函数，因此升级到django 1.4的项目应更新它们的 manage.py . （旧文体） manage.py 将继续工作，直到Django 1.6。在1.5中，它将上升 DeprecationWarning ）
新推荐 manage.py 文件应如下所示：
#!/usr/bin/env python
import os, sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
{{{{ project_name }}}} 应替换为实际项目的python包名称。
如果设置，则使用项目名称前缀（例如 myproject.settings ， ROOT_URLCONF = "myproject.urls" 等等），新的 manage.py 将需要向上移动一个目录，因此它位于项目包之外，而不是与 settings.py 和 urls.py .
例如，具有以下布局：
manage.py
mysite/
__init__.py
settings.py
urls.py
myapp/
__init__.py
models.py
你可以导入 mysite.settings ， mysite.urls 和 mysite.myapp ，但不是 settings ， urls 或 myapp 作为顶级模块。
作为顶级模块导入的任何内容都可以放置在新的 manage.py 。例如，要实现脱钩 myapp 从项目模块中，将其导入为 myapp ，将其放置在 mysite/ 目录：
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py
如果相同的代码导入不一致（有些地方带有项目前缀，有些地方没有），则在切换到新的代码时需要清除导入内容。 manage.py .
这个 startapp 和 startproject 管理命令现在有一个 --template 用于指定自定义应用程序或项目模板的路径或URL的选项。
例如，Django将使用 /path/to/my_project_template 当您运行以下命令时，请执行以下操作：
django-admin.py startproject --template=/path/to/my_project_template myproject
现在还可以将目标目录作为第二个参数提供给 startapp 和 startproject ：
django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project
有关详细信息，请参阅 startapp 和 startproject 文档。
这个 startproject 管理命令现在添加 wsgi.py 初始项目布局的模块，包含可用于 deploying with WSGI app servers .
这个 built-in development server 现在支持使用外部定义的wsgi可调用文件，这使得它可以运行 runserver 使用与部署相同的wsgi配置。新的 WSGI_APPLICATION 通过设置，可以配置哪些wsgi可调用 runserver 使用。
(The runfcgi 管理命令还内部包装通过 WSGI_APPLICATION ）
SELECT FOR UPDATE 支持¶Django 1.4包括 QuerySet.select_for_update() 方法，它生成 SELECT ... FOR UPDATE SQL查询。这将锁定行，直到事务结束，这意味着其他事务无法修改或删除与 FOR UPDATE 查询。
有关更多详细信息，请参阅 select_for_update() .
Model.objects.bulk_create 在ORM中¶此方法允许您更高效地创建多个对象。如果有许多对象，它会导致性能显著提高。
Django在内部使用这一点，这意味着一些操作（如测试套件的数据库设置）因此获得了性能优势。
见 bulk_create() 有关详细信息，请参阅文档。
Django的认证系统 (django.contrib.auth ）使用单向算法存储密码。Django 1.3使用 SHA1 算法，但不断提高的处理器速度和理论攻击表明，sha1并不像我们希望的那样安全。因此，django 1.4引入了一个新的密码存储系统：默认情况下，django现在使用 PBKDF2 算法（按照 NIST) . 您也可以轻松地选择不同的算法（包括 bcrypt 算法。有关详细信息，请参阅 Django如何存储密码 .
我们已经切换了管理和其他捆绑模板以使用HTML5 doctype。虽然Django会小心地保持与旧浏览器的兼容性，但这种更改意味着您可以在管理页面中使用所需的任何HTML5功能，而不必丢失HTML有效性或重写提供的模板来更改doctype。
在Django 1.4之前， admin 应用程序允许您通过指定字段查找来指定更改列表筛选器，但它不允许您创建自定义筛选器。这已经用一个简单的API（以前在内部使用，称为“filterspec”）进行了修正。有关更多详细信息，请参阅 list_filter .
管理员更改列表现在支持对多个列进行排序。它尊重 ordering 属性和通过单击标题对多个列进行排序是为了模仿桌面GUI的行为而设计的。我们还增加了一个 get_ordering() 动态指定排序的方法（即，取决于请求）。
ModelAdmin 方法¶我们增加了一个 save_related() 方法到 ModelAdmin 以便于自定义相关对象在管理中的保存方式。
另外两个新的 ModelAdmin 方法， get_list_display() 和 get_list_display_links() 启用显示在管理更改列表上的字段和链接的动态自定义。
管理内联现在只允许用户有权限的那些操作。为了 ManyToMany 与自动创建的中间模型（没有自己的权限）的关系，相关模型的更改权限决定用户是否具有添加、更改或删除关系的权限。
Django 1.4添加了用于签名值的低级API和用于设置和读取已签名Cookie的高级API，这是Web应用程序中最常见的签名用途之一。
见 cryptographic signing 有关详细信息，请参阅文档。
以前的 FormWizard 从 django.contrib.formtools 已替换为基于django 1.3中引入的基于类的视图的新实现。它具有可插入的存储API，并且不需要向导为前面的每个步骤传递隐藏字段。
Django1.4带有基于会话的存储后端和基于cookie的存储后端。后者使用工具 cryptographic signing Django1.4中还引入了将向导状态存储在用户cookies中的功能。
reverse_lazy¶延迟评估的版本 reverse() 添加以允许在加载项目的urlconf之前使用url反转。
Django现在可以在使用新的时在URL模式中查找语言前置 i18n_patterns() 助手功能。现在还可以使用定义可翻译的URL模式 django.utils.translation.ugettext_lazy() 。看见 国际化：在URL模式中 了解有关语言前置以及如何国际化URL模式的更多信息。
{{% trans %}} 和 {{% blocktrans %}}¶这个 contextual translation Django 1.3通过 pgettext 函数已扩展到 trans 和 blocktrans 使用新的模板标记 context 关键字。
SingleObjectMixin 乌尔康夫克沃斯¶两个新属性， pk_url_kwarg 和 slug_url_kwarg ，已添加到 SingleObjectMixin 启用用于单个对象通用视图的urlconf关键字参数的自定义。
*args 和 **kwargs 支持模板标记帮助器函数¶这个 simple_tag ， inclusion_tag 新引进的 assignment_tag 模板助手函数现在可以接受任意数量的位置或关键字参数。例如：：
@register.simple_tag
def my_tag(a, b, *args, **kwargs):
warning = kwargs["warning"]
profile = kwargs["profile"]
...
return ...
然后，在模板中，可以将任意数量的参数传递给模板标记。例如：
{% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}
TEMPLATE_DEBUG 模式¶在先前版本的django中，每当 TEMPLATE_DEBUG 设置是 True ，在模板呈现期间引发的任何异常（甚至与模板语法无关的异常）都包装在 TemplateSyntaxError 并重新提出。这样做是为了在Debug500页面中提供详细的模板源位置信息。
在django 1.4中，异常不再被包装。相反，原始异常是用源信息注释的。这意味着从模板呈现中捕获异常现在是一致的，不管 TEMPLATE_DEBUG 不需要抓取和打开 TemplateSyntaxError 以便捕获其他错误。
truncatechars 模板滤波器¶此新筛选器将字符串截断为不超过指定的字符数。截断的字符串以可翻译省略号序列（“…”）结尾。参见文档 truncatechars 了解更多详细信息。
static 模板标签¶这个 staticfiles Conrib应用程序有了一个新的 static 模板标记，以引用与 STATICFILES_STORAGE 存储后端。它使用存储后端的 url 方法，因此支持高级功能，如 serving files from a cloud service 。
CachedStaticFilesStorage 存储后端¶这个 staticfiles Contrib应用程序现在有一个 django.contrib.staticfiles.storage.CachedStaticFilesStorage 缓存其保存的文件的后端（运行 collectstatic 管理命令）。例如，文件 css/styles.css 也将另存为 css/styles.55e7cbb9ba48.css
我们添加了一个中间件，可以轻松地防止 clickjacking 使用 X-Frame-Options 标题。由于向后兼容性的原因，它在默认情况下没有启用，但您几乎肯定希望 enable it 帮助插入支持头部的浏览器的安全漏洞。
我们对CSRF功能做了各种改进，包括 ensure_csrf_cookie() decorator，可以帮助处理Ajax重站点；保护Put和Delete请求；以及 CSRF_COOKIE_SECURE 和 CSRF_COOKIE_PATH 设置，可以提高CSRF保护的安全性和实用性。见 CSRF docs 更多信息。
我们增加了两个功能修饰符， sensitive_variables() 和 sensitive_post_parameters() ，以允许指定局部变量和post参数，这些变量可能包含敏感信息，应该从错误报告中筛选出来。
现在，系统地从某些视图的错误报告中筛选出所有post参数。 (login ， password_reset_confirm ， password_change 和 add_view 在里面 django.contrib.auth.views 以及 user_change_password 在管理应用程序中）防止敏感信息（如用户密码）泄漏。
您可以通过编写一个 custom filter . 有关更多信息，请参阅 Filtering error reports .
Django 1.4现在可以更好地处理新的IPv6地址 GenericIPAddressField 模型场， GenericIPAddressField 表单域和验证程序 validate_ipv46_address 和 validate_ipv6_address .
中的基类 django.test 现在，有一些帮助者可以比较HTML，而不会忽略空白、引述/排序参数和结束自结束标记之间的不相关差异。您可以直接将HTML与新的 assertHTMLEqual() 和 assertHTMLNotEqual() 断言，或使用 html=True 旗带 assertContains() 和 assertNotContains() 测试客户端的响应是否包含给定的HTML片段。见 assertions documentation
两新 date 添加了用于模板筛选器、模板标记和 格式本地化 ：
e --给定日期时间对象的时区名称
o --ISO 8601年号
请确保更新您的 custom format files 如果它们包含 e 或 o 格式字符串。例如，以前的西班牙语本地化格式只转义了 d 设置字符格式：
DATE_FORMAT = r"j \de F \de Y"
但现在它也需要逃脱 e 和 o ：：
DATE_FORMAT = r"j \d\e F \d\e Y"
有关详细信息，请参阅 date 文档。
Django 1.4还包括一些较小的改进，值得注意：
技术500页中更有用的stacktrace。引用Django框架代码的堆栈跟踪中的帧将变暗，而应用程序代码中的帧将稍微强调。此更改使扫描StackTrace以查找应用程序代码中的问题更加容易。
Tablespace support 在PostgreSQL中。
的可自定义名称 simple_tag() .
在文档中， security overview 页。
这个 django.contrib.auth.models.check_password 函数已移动到 django.contrib.auth.hashers 模块。从旧位置导入它仍然有效，但您应该更新导入。
这个 collectstatic 管理命令现在有一个 --clear 选项在复制或链接静态文件之前删除目标中的所有文件。
现在可以在使用mysql和innodb数据库引擎时加载包含前向引用的fixture。
已将新的403响应处理程序添加为 'django.views.defaults.permission_denied' . 您可以通过设置 django.conf.urls.handler403 . 请参阅有关的文档 the 403 (HTTP Forbidden) view 更多信息。
这个 makemessages Command使用了一个新的、更精确的词法分析器， JsLex ，用于从JavaScript文件中提取可翻译的字符串。
这个 trans 模板标记现在接受一个可选的 as 参数来检索转换字符串而不显示它，而是设置模板上下文变量。
这个 if 模板标记现在支持 {{% elif %}} 条款。
如果你的django应用在代理服务器后面，你可能会发现新的 SECURE_PROXY_SSL_HEADER 设置有用。它解决了您的代理“吃”的问题，即请求通过HTTPS传入。但只有当你知道自己在做什么的时候才使用这个设置。
当出现以下情况时，提供了新的纯文本版本的HTTP 500状态代码内部错误页面 DEBUG 是 True 现在，当Django检测到请求源自JavaScript代码时，将发送给客户端。 (is_ajax() 用于此。）
与它的HTML对应物一样，它包含一组关于应用程序状态的不同信息。
当调试与客户端JavaScript的交互时，这应该使阅读更容易。
增加了 makemessages --no-location 选择权。
改变了 locmem 缓存要使用的后端 pickle.HIGHEST_PROTOCOL 为了更好地与其他缓存后端兼容。
在ORM中添加了用于生成的支持 SELECT 包含以下内容的查询 DISTINCT ON .
这个 distinct() QuerySet 方法现在接受模型字段名称的可选列表。如果指定，则 DISTINCT 语句仅限于这些字段。这仅在PostgreSQL中受支持。
有关更多详细信息，请参阅 distinct() .
如果您在名称中包含URL，管理员登录页面将添加密码重置链接 'admin_password_reset' 在你的 urls.py ，因此，插入内置的密码重置机制并使其可用现在容易得多。有关详情，请参阅 添加密码重置功能 。
现在，MySQL数据库后端可以使用由5.0.3版或更新版本的MySQL通过InnoDB存储引擎实现的保存点功能。
现在可以将初始值传递给模型表单，这些表单是从工厂函数返回的模型表单集和内联模型表单集的一部分。 modelformset_factory 和 inlineformset_factory 分别与常规表单集相同。但是，初始值只适用于额外的表单，即那些未绑定到现有模型实例的表单。
站点地图框架现在可以使用新的 Sitemap.protocol 类属性。
一个新的 django.test.SimpleTestCase 亚类 unittest.TestCase 比…轻 django.test.TestCase 还有公司。它在不需要命中数据库的测试中很有用。见 Django单元测试类的层次结构 .
用空的或已知的 SECRET_KEY 禁用Django的许多安全保护，并可能导致远程代码执行漏洞。任何Django站点都不应该没有 SECRET_KEY .
在Django 1.4中，Django以空开始 SECRET_KEY 将引发一个 DeprecationWarning .在Django 1.5中，它将引发异常，Django将拒绝开始。由于在没有的情况下运行Django后果的严重性，这比通常的弃用路径略有加快 SECRET_KEY 。
django.contrib.admin¶包含的管理应用程序 django.contrib.admin 在很长一段时间内附带了一组默认的静态文件，如javascript、图像和样式表。Django 1.3添加了一个新的contrib应用程序 django.contrib.staticfiles 以通用的方式处理这些文件，并为应用程序中包含的静态文件定义约定。
从Django 1.4开始，管理员的静态文件也遵循这一约定，以使文件更易于部署。在以前的Django版本中，定义一个 ADMIN_MEDIA_PREFIX 设置为指向管理员的静态文件在Web服务器上所在的URL。此设置现在已弃用，并被更通用的设置所取代 STATIC_URL 。Django现在可以在URL下找到admin静态文件 <STATIC_URL>/admin/ 。
如果您以前使用过URL路径 ADMIN_MEDIA_PREFIX (例如： /media/ )只需确保 STATIC_URL 和 STATIC_ROOT 已配置，并且您的Web服务器正确提供这些文件。开发服务器继续提供管理文件，就像以前一样。请阅读 static files howto 了解更多详细信息。
如果你的 ADMIN_MEDIA_PREFIX 被设置为特定域（例如 http://media.example.com/admin/ ），请确保还设置您的 STATIC_URL 设置为正确的URL --例如， http://media.example.com/ 。
警告
如果您隐式地依赖Django源代码中管理静态文件的路径，则需要更新该路径。文件已从移动 django/contrib/admin/media/ 到 django/contrib/admin/static/admin/ .
Django还没有明确的管理应用程序支持哪些浏览器的政策。我们的新政策使现有做法正式化： YUI's A-grade 浏览器应该提供全功能的管理体验，除了不再受支持的Internet Explorer 6之外，还有一个显著的例外。
IE6发布于10多年前，它对现代网络开发施加了许多限制。这一政策的实际影响是，贡献者可以自由地改进管理，而不考虑这些限制。
这项新政策 has no impact 在您使用Django开发的网站上。它仅适用于Django管理员。可以随意开发与任何浏览器兼容的应用程序。
作为改进管理员更改列表排序界面性能和可用性的一部分，以及 horizontal 和 vertical “过滤器”小部件，一些图标文件被删除并分组为两个sprite文件。
明确地： selector-add.gif ， selector-addall.gif ， selector-remove.gif ， selector-removeall.gif ， selector_stacked-add.gif 和 selector_stacked-remove.gif 合并成 selector-icons.gif ；和 arrow-up.gif 和 arrow-down.gif 合并成 sorting-icons.gif .
如果您使用这些图标自定义管理员，那么您需要用自己的图标替换它们，或者从以前的版本获取文件。
为了避免与其他常见的CSS类名（例如“button”）冲突，我们在主管理窗体、堆叠的内联窗体和表格的内联单元格中的表单字段名自动生成的所有CSS类名中添加了前缀（“field-”）。如果以前使用普通字段名作为自定义样式或javascript转换的选择器，那么在自定义样式表或javascript文件中需要考虑该前缀。
Django 1.3更改了在Django许多地方使用的加密签名机制。虽然Django1.3保留了接受以前方法生成的哈希的回退，但这些回退在Django1.4中被删除。
因此，如果直接从1.2或更早版本升级到django 1.4，则可能会丢失/使使用旧方法加密签名的某些数据块失效。为了避免这种情况，请先使用django 1.3一段时间，以允许签名数据自然过期。下面详细介绍了受影响的部分，其中1）忽略此建议的后果，2）运行django 1.3所需的时间，以使数据过期或变得不相关。
contrib.sessions 数据完整性检查
结果：用户将被注销，会话数据将丢失。
时间段：定义人 SESSION_COOKIE_AGE .
contrib.auth 密码重置哈希
结果：升级前的密码重置链接将不起作用。
时间段：定义者 PASSWORD_RESET_TIMEOUT_DAYS 。
与表格相关的哈希：它们的生存期要短得多，并且仅与用户可能填写升级前Django实例生成的表格并尝试将其提交给升级后的Django实例的短窗口相关：
contrib.comments 窗体安全哈希
结果：用户将看到验证错误“安全哈希失败”。
时间段：期望用户填写评论表单的时间量。
FormWizard 安全散列
结果：用户将看到有关表单已过期的错误，并将被发送回向导的第一页，丢失迄今为止输入的数据。
时间段：希望用户填写受影响表单的时间量。
CSRF检查
注意：这实际上是一个django 1.1回退，而不是django 1.2，它仅适用于从1.1升级的情况。
结果：用户将看到403错误与任何受CSRF保护的post表单。
时间段：您希望用户填写此类表单的时间。
contrib.auth 用户密码哈希升级序列
结果：当每个用户的密码在1.4中写入数据库时，它将被更新为更强的密码哈希。这意味着如果升级到1.4，然后需要降级到1.3，1.3版将无法读取更新的密码。
补救措施：设定 PASSWORD_HASHERS 在最初升级到1.4时使用原始密码散列。在你确认你的应用程序与Django1.4很好地配合后，你就不必回滚到1.3了，启用新的密码散列。
django.contrib.flatpages¶从1.4开始， FlatpageFallbackMiddleware 仅当生成的URL引用现有的平面图时添加尾随斜杠并重定向。例如，请求 /notaflatpageoravalidurl 在以前的版本中，将重定向到 /notaflatpageoravalidurl/ 这将导致404。请求 /notaflatpageoravalidurl 现在将立即提高404。
此外，通过flatpages返回的重定向现在是永久的（状态代码为301），以匹配 CommonMiddleware .
datetime 和 time¶由于时区支持，根据ECMA-262规范，我们对JSON序列化程序进行了更改：
它包括用于感知日期时间对象的时区。它会对感知时间对象引发异常。
它包括日期时间和时间对象的毫秒数。还有一些精度损失，因为python存储微秒（6位），而json只支持毫秒（3位）。但是，它比完全丢弃微秒要好。
我们将XML序列化程序更改为对日期时间使用ISO8601格式。信 T 用于分隔日期部分和时间部分，而不是空格。时区信息包含在 [+-]HH:MM 格式。
尽管序列化程序现在在创建设备时使用这些新格式，但它们仍然可以加载使用旧格式的设备。
supports_timezone 改为 False SQLite¶数据库功能 supports_timezone 曾经是 True 对于SQLite。实际上，如果保存了一个感知日期时间对象，则sqlite存储了一个包含UTC偏移量的字符串。但是，当从数据库加载值时，这个偏移量被忽略，这可能会损坏数据。
在时区支持的上下文中，此标志已更改为 False 和datetime现在存储在sqlite中，没有时区信息。什么时候？ USE_TZ 是 False ，如果尝试保存一个感知的日期时间对象，Django将引发一个异常。
MySQLdb -特定例外¶MySQL后端在历史上 MySQLdb.OperationalError 当查询触发异常时。我们已经解决了这个问题，现在我们提出 django.db.DatabaseError 相反。如果你在测试 MySQLdb.OperationalError ，您需要更新 except 条款。
DatabaseWrapper 对象（即引用的连接对象 django.db.connection 和 django.db.connections["some_alias"] ）以前是本地线程。它们现在是全局对象，以便在多个线程之间共享。虽然各个连接对象现在是全局的，但是 django.db.connections 引用这些对象的字典仍然是线程本地的。因此，如果您只是使用ORM或 DatabaseWrapper.cursor() 然后，行为仍然和以前一样。但是，请注意 django.db.connection 不直接引用默认值 DatabaseWrapper 对象，现在是访问该对象属性的代理。如果你需要访问 DatabaseWrapper 使用对象 django.db.connections[DEFAULT_DB_ALIAS] 相反。
作为此更改的一部分，所有底层SQLite连接现在都启用了潜在的线程共享(通过传递 check_same_thread=False 属性为 pysqlite )。 DatabaseWrapper 但是，通过在默认情况下禁用线程共享来保留以前的行为，因此这不会影响任何纯粹依赖ORM或 DatabaseWrapper.cursor() 。
最后，虽然现在可以在线程之间传递连接，但Django不做任何努力来同步对底层后端的访问。并发行为由底层后端实现定义。查看他们的文档以了解详细信息。
COMMENTS_BANNED_USERS_GROUP 设置¶Django的评论在历史上支持排除特殊用户组的评论，但我们从未正确地记录该功能，并且没有在应用程序的其他部分（如模板标签）强制排除。为了解决这个问题，我们从feed类中删除了代码。
如果您依赖该功能并希望恢复旧行为，请使用自定义注释模型管理器排除用户组，如下所示：
from django.conf import settings
from django.contrib.comments.managers import CommentManager
class BanningCommentManager(CommentManager):
def get_query_set(self):
qs = super().get_query_set()
if getattr(settings, "COMMENTS_BANNED_USERS_GROUP", None):
where = [
"user_id NOT IN (SELECT user_id FROM auth_user_groups WHERE group_id = %s)"
]
params = [settings.COMMENTS_BANNED_USERS_GROUP]
qs = qs.extra(where=where, params=params)
return qs
将此模型管理器保存在自定义注释应用程序中（例如 my_comments_app/managers.py ）并将其添加到您的自定义评论应用程序模型中：
from django.db import models
from django.contrib.comments.models import Comment
from my_comments_app.managers import BanningCommentManager
class CommentWithTitle(Comment):
title = models.CharField(max_length=300)
objects = BanningCommentManager()
IGNORABLE_404_STARTS 和 IGNORABLE_404_ENDS 设置¶在django 1.3之前，可以从django中排除一些URL 404 error reporting 通过向添加前缀 IGNORABLE_404_STARTS 后缀 IGNORABLE_404_ENDS .
在Django 1.4中，这两个设置被取代 IGNORABLE_404_URLS ，这是已编译正则表达式的列表。Django不会发送一封电子邮件，邮件中显示404个与它们匹配的URL错误。
此外，以前的设置有一些相当随意的默认值：
IGNORABLE_404_STARTS = ("/cgi-bin/", "/_vti_bin", "/_vti_inf")
IGNORABLE_404_ENDS = (
"mail.pl",
"mailform.pl",
"mail.cgi",
"mailform.cgi",
"favicon.ico",
".php",
)
决定你的网站是否有遗产不是Django的职责 /cgi-bin/ 节或A favicon.ico . 因此，默认值为 IGNORABLE_404_URLS ， IGNORABLE_404_STARTS 和 IGNORABLE_404_ENDS 现在都是空的。
如果你已经定制了 IGNORABLE_404_STARTS 或 IGNORABLE_404_ENDS 或者，如果要保留旧的默认值，则应在设置文件中添加以下行：
import re
IGNORABLE_404_URLS = (
# for each <prefix> in IGNORABLE_404_STARTS
re.compile(r"^<prefix>"),
# for each <suffix> in IGNORABLE_404_ENDS
re.compile(r"<suffix>$"),
)
不要忘记转义在正则表达式中有特殊意义的字符，例如句点。
以前，Django的 CSRF protection 仅针对邮政请求提供保护。由于在Ajax应用程序中使用Put和Delete方法变得越来越普遍，我们现在通过 RFC 2616 --也就是说，我们免除了GET、HEAD、OPTIONS和TRACE，并对其他所有内容实施保护。
如果在Ajax应用程序中使用Put或Delete方法，请参见 instructions about using AJAX and CSRF .
subject_template_name¶这个 password_reset 视图 django.contrib.auth 现在接受 subject_template_name 参数，作为关键字参数传递给密码保存窗体。如果将此视图与自定义密码重置表单一起使用，则需要确保表单的 save() 方法接受此关键字参数。
django.core.template_loaders¶这是一个别名 django.template.loader 自2005年以来，我们移除了它，但由于折旧的时间过长，没有发出警告。如果您的代码仍然引用这个，请使用 django.template.loader 相反。
django.db.models.fields.URLField.verify_exists¶由于棘手的性能和安全问题，此功能已被删除。任何现有的 verify_exists 应该移除。
django.core.files.storage.Storage.open¶这个 open 用于获取模糊参数的基存储类的方法 mixin 这允许您动态地更改返回文件对象的基类。此已删除。在罕见的情况下，你依赖 mixin 参数，您可以通过重写 open 方法，如：
from django.core.files import File
from django.core.files.storage import FileSystemStorage
class Spam(File):
"""
Spam, spam, spam, spam and spam.
"""
def ham(self):
return "eggs"
class SpamStorage(FileSystemStorage):
"""
A custom file storage backend.
"""
def open(self, name, mode="rb"):
return Spam(open(self.path(name), mode))
yaml.safe_load¶yaml.load 能够构造任何python对象，如果处理来自不受信任源的yaml文档，则可能触发任意代码执行。Django的yaml反序列化程序不需要这个特性，它的主要用途是加载由简单对象组成的设备。尽管设备是可信数据，但是yaml反序列化程序现在使用 yaml.safe_load 为了额外的安全。
urlize 过滤器不再逐出每个URL¶当URL包含 %xx 序列，在哪里 xx 是两个十六进制数字， urlize 现在假设URL已经被转义，不再应用URL转义。对于未加引号的表单包含 %xx 顺序，但是这样的URL不太可能在野外发生，因为它们也会混淆浏览器。
assertTemplateUsed 和 assertTemplateNotUsed 作为上下文管理器¶现在可以检查模板是否在代码块中使用 assertTemplateUsed() 和 assertTemplateNotUsed() . 它们可以用作上下文管理器：
with self.assertTemplateUsed("index.html"):
render_to_string("index.html")
with self.assertTemplateNotUsed("base.html"):
render_to_string("index.html")
默认测试运行程序在测试执行后不再恢复数据库连接。这样可以防止生产数据库暴露于仍在运行的潜在线程，并尝试创建新的连接。
如果您的代码依赖于在测试执行后创建的生产数据库的连接，那么您可以通过子类化恢复以前的行为。 DjangoTestRunner 并超越它 teardown_databases() 方法。
manage.py help¶manage.py help 现在按应用程序对可用命令进行分组。如果您依赖于这个命令的输出——例如，如果您分析了它——那么您将需要更新代码。要获取脚本中所有可用管理命令的列表，请使用 manage.py help --commands 相反。
extends 模板标签¶以前， extends 标记使用了错误的方法来分析参数，这可能导致它错误地将参数视为字符串文字而不是字符串文字。 parser.compile_filter 像其他标签一样。
标签的内部不是官方稳定API的一部分，而是为了全面公开， ExtendsNode.__init__ 定义已更改，这可能会破坏使用此类的任何自定义标记。
在1.4之前，当为字段设置auto_now或auto_now_add时，为缺少特定日期或日期时间值的fixture对象插入了默认值。这是不应该起作用的，在1.4中加载这样不完整的固定装置将失败。因为fixture是原始导入，所以它们应该显式指定所有字段值，而不考虑模型上的字段选项。
开发服务器现在默认情况下是多线程的。使用 runserver --nothreading 在开发服务器中禁用线程的选项：
django-admin.py runserver --nothreading
在django 1.4之前，无论过滤器的安全模式设置如何，属性都包含在任何降价输出中。在版本>2.1的python markdown库中，添加了一个启用属性选项。当safe参数传递到markdown筛选器时，两个 safe_mode=True 和 enable_attributes=False 设置选项。如果使用的python markdown库版本低于2.1，则会发出一条警告，说明输出不安全。
在Django 1.3中， get_initial 方法 django.views.generic.edit.FormMixin 全班都在上课 initial 字典。这已被修复以返回此字典的副本，因此表单实例可以修改其初始数据，而不会与类变量混淆。
cache_page decorator¶一些传统的调用方式 cache_page() 已弃用。请参阅文档以了解使用此修饰符的正确方法。
Django 1.3放弃了对8.0以上的PostgreSQL版本的支持，我们建议使用较新的版本，因为性能得到了改善，更重要的是，8.0和8.1的上游支持期即将结束（2010年11月）。
Django1.4进一步考虑了这一策略，并将8.2设置为其官方支持的最低PostgreSQL版本。
当我们添加 logging support 在1.3中的Django中，管理错误电子邮件支持被移动到 django.utils.log.AdminEmailHandler ，附加到 'django.request' 记录器。为了保持错误电子邮件的既定行为，请 'django.request' 只有当 DEBUG 是 False .
为了提高请求的错误日志记录的灵活性， 'django.request' 现在，无论 DEBUG ，新项目的默认设置文件现在包含附加到 django.utils.log.AdminEmailHandler 防止管理错误电子邮件进入 DEBUG 模式：
LOGGING = {
# ...
"filters": {
"require_debug_false": {
"()": "django.utils.log.RequireDebugFalse",
}
},
"handlers": {
"mail_admins": {
"level": "ERROR",
"filters": ["require_debug_false"],
"class": "django.utils.log.AdminEmailHandler",
}
},
}
如果您的项目是在此更改之前创建的，则 LOGGING 设置将不包括此新筛选器。为了保持向后兼容性，Django将检测到 'mail_admins' 处理程序配置不包括 'filters' 并将自动为您添加此筛选器并发出挂起的弃用警告。在Django 1.5中，这将成为一个警告，在Django 1.6中，向后兼容垫片将被完全删除。
任何 'filters' 钥匙下 'mail_admins' 处理程序将禁用此向后兼容填充程序和取消预测警告。
django.conf.urls.defaults¶在Django 1.3之前， include() ， patterns() 和 url() 函数，加上 handler404 和 handler500 位于 django.conf.urls.defaults 模块。
在Django 1.4，他们住在 django.conf.urls .
django.contrib.databrowse¶databrowse已经有一段时间没有看到活动的开发，这并没有显示任何变化的迹象。有人建议 GSOC project 将databrowse的功能集成到管理中，但没有任何进展。尽管databrowse已被弃用，但 django.contrib.admin 提供类似的功能集仍然是可能的。
驱动数据浏览的代码与Django本身具有相同的许可条款，因此它可以作为第三方项目被个人或团体采用。
django.core.management.setup_environ¶此功能暂时修改 sys.path 为了使父“项目”目录在旧公寓下可导入 startproject 布局。此函数现在已被弃用，因为它的路径解决方案不再需要与新的 manage.py 和默认项目布局。
该功能从未被记录过或作为公共API的一部分，但广泛建议在为用户脚本设置“Django环境”时使用它。应通过设置 DJANGO_SETTINGS_MODULE 环境变量或使用 django.conf.settings.configure() 。
django.core.management.execute_manager¶此函数以前由 manage.py 执行管理命令。它与 django.core.management.execute_from_command_line ，除了它首先调用 setup_environ ，现已弃用。像这样的， execute_manager 也被否决； execute_from_command_line 可以改为使用。这两个函数都没有作为公共API的一部分进行记录，但是由于在现有的API中使用，因此需要一个弃用路径。 manage.py 文件夹。
is_safe 和 needs_autoescape 模板筛选器的属性¶两个标识， is_safe 和 needs_autoescape 定义每个模板过滤器如何与Django的自动转义行为交互。它们曾经是过滤函数的属性：
@register.filter
def noop(value):
return value
noop.is_safe = True
然而，这项技术在与装饰师结合时，特别是在 @stringfilter . 现在，标志是的关键字参数 @register.filter ：：
@register.filter(is_safe=True)
def noop(value):
return value
见 filters and auto-escaping 更多信息。
INSTALLED_APPS¶直到Django 1.3， INSTALLED_APPS 在应用程序名称中接受通配符，例如 django.contrib.* . 扩展是由基于文件系统的 from <package> import * . 不幸的是，这是不可靠的。
这种行为从未被记录下来。由于它是非pythonic的，因此在Django 1.4中删除了它。如果您依赖它，则必须编辑您的设置文件以显式列出所有应用程序。
HttpRequest.raw_post_data renamed to HttpRequest.body¶这个属性的名称很混乱 HttpRequest.raw_post_data 但它实际上提供了HTTP请求的主体。它被重命名为 HttpRequest.body 和 HttpRequest.raw_post_data 已弃用。
django.contrib.sitemaps 具有潜在性能影响的错误修复¶在以前的版本中， Paginator 网站图类中使用的对象已被缓存，这可能导致网站图过时。我们已经删除了缓存，因此对站点地图的每个请求现在都会创建一个新的paginator对象并调用 items() 方法 Sitemap 子类。取决于你的 items() 方法正在执行，这可能会对性能产生负面影响。要减轻性能影响，请考虑使用 caching framework 在你之内 Sitemap 子类。
早于2.1的python markdown版本不支持禁用属性的选项。作为一个安全问题，Markup Contrib应用程序在1.5中加速折旧时间表下不支持此库的早期版本。
7月 22, 2024