Django 1.2 发行说明 — Django 文档

来自菜鸟教程
Django/docs/2.2.x/releases/1.2
跳转至：导航、​搜索

Django 1.2 发行说明

2010 年 5 月 17 日。

欢迎使用 Django 1.2！

将近一年的时间，Django 1.2 包含了令人印象深刻的 新特性 列表和许多错误修复。 这些发行说明涵盖了新功能，以及从 Django 1.1 或更旧版本升级时需要注意的重要更改。

概述

Django 1.2 引入了几个重要的新特性，包括：

这些只是亮点； 完整的详细信息和完整的功能列表 可以在下面找到 。

也可以看看

Django Advent 用一系列文章和教程深入介绍了 Django 1.2 的发布，深入介绍了一些新功能。


根据 我们的 API 稳定性政策 政策，我们尽可能以向后兼容的方式引入了这些功能。

然而，少数功能 已经 发生了变化，对于某些用户来说，将向后不兼容。 较大的变化是：

  • 已取消对 Python 2.3 的支持。 请参阅下面的完整注释。

  • 新的 CSRF 保护框架不向后兼容旧系统。 在 Django 1.4 中删除旧系统之前，旧系统的用户不会受到影响。

    然而，升级到新的 CSRF 保护框架需要一些重要的向后不兼容的更改，详见下面的 CSRF 保护 。

  • 自定义 Field 子类的作者应该意识到许多方法的原型发生了变化，详见下面 Field 上的 get_db_prep_*() 方法。

  • 模板标签的内部结构发生了一些变化； 需要存储状态的自定义模板标签的作者（例如 自定义控制流标签）应确保其代码遵循 有状态模板标签 的新规则

  • user_passes_test()、login_required() 和 permission_required()，来自 django.contrib.auth 的装饰器仅适用于函数和不再研究方法。 有一个简单的单行修复 ，详述如下 。

同样，这些只是影响大多数用户的重要功能。 强烈建议从以前版本的 Django 升级的用户查阅 向后不兼容更改 的完整列表和 不推荐使用的功能列表 。


Python兼容性

虽然不是新功能，但重要的是要注意 Django 1.2 引入了自 Django 首次公开亮相以来我们 Python 兼容性政策的第一次转变。 以前的 Django 版本在 2.3 及以上的 2.x Python 版本上进行了测试和支持； 然而，Django 1.2 放弃了对 Python 2.3 的官方支持。 因此，Django 所需的最低 Python 版本现在是 2.4，并且 Django 在 Python 2.4、2.5 和 2.6 上经过测试和支持，并将在尚未发布的 Python 2.7 上得到支持。

此更改应仅影响少数 Django 用户，因为当今大多数操作系统供应商都将 Python 2.4 或更高版本作为其默认版本提供。 但是，如果您仍在使用 Python 2.3，则需要坚持使用 Django 1.1，直到您可以升级； 根据 我们的支持政策 ，Django 1.1 将继续获得安全支持，直到 Django 1.3 发布。

目前正在开发 Django 整体 2.x Python 支持以及最终过渡到 Python 3.x 的路线图，并将在 Django 1.3 发布之前公布。


Django 1.2 中的新功能

支持多个数据库

Django 1.2 添加了在 Django 项目中使用 多个数据库 的能力。 可以使用 QuerySet 对象上的 using() 方法在特定数据库上发出查询。 通过在调用 save() 时提供 using 参数，可以将单个对象保存到特定数据库。


模型验证

模型实例现在支持 [X37X] 验证它们自己的数据 ，并且模型和表单字段现在都接受 验证器 的可配置列表，指定可重用的封装验证行为。 但是请注意，验证仍必须明确执行。 简单地调用模型实例的 save() 方法不会对该实例的数据执行任何验证。


改进的 CSRF 保护

Django 现在对 跨站请求伪造 (CSRF) 攻击 的防护有了很大改进。 当恶意网站包含链接、表单按钮或一些 JavaScript，旨在使用在其浏览器中访问恶意网站的登录用户的凭据对您的网站执行某些操作时，就会发生此类攻击。 还涵盖了一种相关类型的攻击，即“登录 CSRF”，其中攻击站点欺骗用户的浏览器使用其他人的凭据登录站点。


消息框架

Django 现在包含一个强大且可配置的 消息框架 ，内置支持基于 cookie 和会话的消息传递，适用于匿名和经过身份验证的客户端。 消息框架替换了已弃用的用户消息 API，并允许您在一个请求中临时存储消息并检索它们以在后续请求（通常是下一个请求）中显示。


对象级权限

添加了用于在每个对象级别指定权限的基础。 尽管在核心中没有实现这一点，但自定义身份验证后端可以提供此实现，并将由 django.contrib.auth.models.User 使用。 有关更多信息，请参阅 身份验证文档 。


匿名用户的权限

如果您提供自定义身份验证后端并将 supports_anonymous_user 设置为 True，AnonymousUser 将检查后端的权限，就像 User 已经做的那样。 这对于集中权限处理很有用 - 应用程序始终可以将是否允许某事的问题委托给授权/身份验证后端。 有关更多详细信息，请参阅 身份验证文档 。


用户名要求放宽

内置 User 模型的 username 字段现在允许更广泛的字符，包括 @、+、. 和- 字符。


电子邮件后端

您现在可以 配置 Django 发送电子邮件的方式 。 您现在可以选择一个可配置的电子邮件后端来发送消息，而不是使用 SMTP 发送所有电子邮件。 如果您的托管服务提供商使用沙箱或其他一些非 SMTP 技术发送邮件，您现在可以构建一个电子邮件后端，允许 Django 的标准 邮件发送方法 使用这些设施。

这也使调试邮件发送变得更容易。 Django 附带的后端实现允许您将电子邮件发送到 文件 、 控制台 或 内存 。 您甚至可以将所有电子邮件配置为 丢弃 。


“智能” :ttag:`if` 标签

:ttag:`if` 标签已升级为更强大。 首先，我们添加了对比较运算符的支持。 您不再需要输入： 

{% ifnotequal a b %}
 ...
{% endifnotequal %}

你现在可以这样做： 

{% if a != b %}
 ...
{% endif %}

真的没有理由再使用 {% ifequal %} 或 {% ifnotequal %}，除非你是怀旧类型。

支持的操作符有 ==、!=、<、>、<=、>=、[ X98X] 和 not in，除了已经支持的 and、or 和 not 之外，所有这些都像 Python 运算符一样工作。

此外，现在可以在 if 表达式中使用过滤器。 例如： 

<div
  {% if user.email|lower == message.recipient|lower %}
    class="highlight"
  {% endif %}
>{{ message }}</div>

模板缓存

在以前的 Django 版本中，每次渲染模板时，它都会从磁盘重新加载。 在 Django 1.2 中，您可以使用 缓存模板加载器 加载模板一次，然后为每个后续渲染缓存结果。 如果您的模板被分解为许多较小的子模板（使用 {% extends %} 或 {% include %} 标签），这会显着提高性能。

作为副作用，现在支持非 Django 模板语言要容易得多。


基于类的模板加载器

作为引入 模板缓存 所做更改的一部分并遵循 Django 的总体趋势，模板加载器 API 已被修改为使用封装在 Python 类中的模板加载机制，而不是函数，这是唯一的方法在 Django 1.1 之前可用。

Django 附带的所有模板加载器 都已移植到新 API，但它们仍然实现基于函数的 API，模板核心机制仍然接受基于函数的加载器（内置或第三方），因此没有立即需要修改现有项目中的 TEMPLATE_LOADERS 设置，如果在 Django 1.3 版本之前保持不变，事情将继续工作。

如果您开发了自己的自定义模板加载器，我们建议考虑将它们移植到基于类的实现，因为与基于函数的加载器向后兼容的代码在 Django 1.2 中开始弃用过程，并将在 Django 1.4 中删除。 在模板 API 参考中对这些加载器类必须实现的 API 进行了描述，您还可以检查 Django 附带的加载器的源代码。


固定装置中的自然键

固定装置现在可以使用 自然键 引用远程对象。 这种查找方案是夹具中基于主键的普通对象引用的替代方案，提高了可读性并解决了引用其主键值可能不可预测或已知的对象的问题。


测试快速失败

django-admin.py 的 :djadmin:`test` 子命令和用于运行 Django 自己的测试套件的 runtests.py 脚本现在都支持 --failfast 选项。 指定后，此选项会导致测试运行器在遇到故障后退出，而不是继续测试运行。 此外，在测试运行期间对 Ctrl-C 的处理已得到改进，以触发从测试运行正常退出，报告中断前运行的测试的详细信息。


BigIntegerField

模型现在可以使用 64 位 BigIntegerField 类型。


改进本地化

Django 的 国际化框架 已经扩展了区域设置感知格式和表单处理。 这意味着，如果启用，模板上的日期和数字将使用为当前语言环境指定的格式显示。 Django 在解析表单中的数据时也会使用本地化格式。 有关更多详细信息，请参阅 格式本地化 。


readonly_fields 在 ModelAdmin

django.contrib.admin.ModelAdmin.readonly_fields 已添加以在模型和内联的添加/更改页面中启用不可编辑的字段。 字段和计算值可以与可编辑字段一起显示。


可定制的语法高亮

您现在可以使用 DJANGO_COLORS 环境变量来修改或禁用 [X89X] 使用的颜色，以提供 语法突出显示 。


作为视图的联合提要

联合提要现在可以直接用作URLconf中的视图。 这意味着您可以完全控制 Feed 的 URL 结构。 与任何其他视图一样，提要视图传递一个 request 对象，因此您可以执行通常对视图执行的任何操作，例如基于用户的访问控制，或将提要设为命名 URL。


吉奥姜戈

GeoDjango 在 1.2 中最重要的新特性是支持多个空间数据库。 因此，现在包括以下 空间数据库后端 ：

  • django.contrib.gis.db.backends.postgis
  • django.contrib.gis.db.backends.mysql
  • django.contrib.gis.db.backends.oracle
  • django.contrib.gis.db.backends.spatialite

GeoDjango 现在支持 PostGIS 1.5 版本中添加的丰富功能。 新功能包括支持 [X37X] 地理类型 和启用 距离查询 与地理坐标系上的非点几何。

添加了对 3D 几何字段的支持，可以通过将 GeometryField 中的 dim 关键字设置为 3 来启用。 Extent3D 聚合和 extent3d() GeoQuerySet 方法作为此功能的一部分添加。

force_rhr()、reverse_geom() 和 geohash() GeoQuerySet 方法是新的。

GEOS 接口已更新为在平台上可用时使用线程安全的 C 库函数。

GDAL 接口现在允许用户在迭代 层 时返回的特征上设置 spatial_filter。

最后，GeoDjango 的文档 现在包含在 Django 中，不再单独托管在 geodjango.org。


新的 now 模板标签格式说明符字符：c 和 u

:ttag:`now` 的参数获得了两个新的格式字符：c 指定日期时间值应采用 ISO 8601 格式，以及 u允许输出日期时间或时间值的微秒部分。

这些也可用于其他部分，如 :tfilter:`date` 和 :tfilter:`time` 模板过滤器、humanize 模板标签库和新的格式本地化框架。


1.2 中向后不兼容的变化

根据 我们的 API 稳定性政策 政策，我们尽可能以向后兼容的方式引入了上述新功能。 这意味着几乎所有与 Django 1.1 一起工作的现有代码将继续与 Django 1.2 一起工作； 但是，此类代码将开始发出警告（有关详细信息，请参见下文）。

然而，少数功能 已经 发生了变化，对于某些用户来说，将立即向后不兼容。 这些更改详述如下。

CSRF 保护

我们对 CSRF 保护的工作方式进行了大量更改，详细信息请参见 CSRF 文档 。 以下是您应该注意的主要变化：

  • CsrfResponseMiddleware 和 CsrfMiddleware 已被弃用，将在 Django 1.4 中完全删除，以支持应插入到表单中的模板标签。

  • 所有 contrib 应用程序都使用 csrf_protect 装饰器来保护视图。 这需要在模板中使用 csrf_token 模板标签。 如果您为 contrib 视图使用了自定义模板，则必须阅读升级说明以修复这些模板。

    文档已删除

    升级说明已在当前 Django 文档中删除。 请参阅 Django 1.3 或更早版本的文档以查找这些说明。

  • CsrfViewMiddleware 默认包含在 MIDDLEWARE_CLASSES 中。 这默认打开 CSRF 保护，因此需要编写接受 POST 请求的视图以与中间件一起使用。 有关如何执行此操作的说明可在 CSRF 文档中找到。

  • 所有的 CSRF 都从 contrib 转移到了核心（在旧位置具有向后兼容的导入，这些导入已被弃用，将在 Django 1.4 中停止支持）。


get_db_prep_*() 方法 Field

在 Django 1.2 之前，自定义 Field 可以选择定义几个函数来支持将 Python 值转换为与数据库兼容的值。 自定义字段可能类似于： 

class CustomModelField(models.Field):
    # ...
    def db_type(self):
        # ...

    def get_db_prep_save(self, value):
        # ...

    def get_db_prep_value(self, value):
        # ...

    def get_db_prep_lookup(self, lookup_type, value):
        # ...

在1.2中，这三个方法在prototype上发生了变化，引入了两个额外的方法： 

class CustomModelField(models.Field):
    # ...

    def db_type(self, connection):
        # ...

    def get_prep_value(self, value):
        # ...

    def get_prep_lookup(self, lookup_type, value):
        # ...

    def get_db_prep_save(self, value, connection):
        # ...

    def get_db_prep_value(self, value, connection, prepared=False):
        # ...

    def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False):
        # ...

这些更改是支持多个数据库所必需的——db_type 和 get_db_prep_* 不能再对其正在准备的数据库做出任何假设。 connection 参数现在提供了准备方法以及正在准备值的特定连接。

存在两种新方法来区分一般数据准备要求和特定于数据库的要求。 prepared 参数用于向数据库准备方法指示是否已执行泛型值准备。 如果向 get_db_prep_*() 调用提供了未准备好的（即 prepared=False）值，则它们应调用相应的 get_prep_*() 调用来执行通用数据准备。

我们提供了转换函数，可以将遵循旧原型的函数透明地转换为与新原型兼容的函数。 但是，这些转换函数将在 Django 1.4 中删除，因此您应该尽快升级您的 Field 定义以使用新的原型。

如果您的 get_db_prep_*() 方法没有使用数据库连接，您应该可以通过将 get_db_prep_value() 重命名为 get_prep_value() 并将 get_db_prep_lookup() 重命名为 [ X152X]。 如果您需要特定于数据库的转换，则需要提供一个实现 get_db_prep_*，它使用 connection 参数来解析特定于数据库的值。


有状态模板标签

在其 Node 子类上存储渲染状态的模板标签一直容易受到线程安全和其他问题的影响； 然而，从 Django 1.2 开始，当与新的 缓存模板加载器 一起使用时，它们也可能会导致问题。

所有内置的 Django 模板标签都可以安全地与缓存的加载器一起使用，但是如果您使用来自第三方包或您自己的代码的自定义模板标签，您应该确保 [X213X ] 每个标签的实现都是线程安全的。 有关更多信息，请参阅 模板标记线程安全注意事项 。

如果您依赖 Django 的模板标签 而不是 线程安全的实现，您可能还需要更新您的模板。 :ttag:`cycle` 标签最有可能以这种方式受到影响，尤其是与 :ttag:`include` 标签一起使用时。 考虑以下模板片段： 

{% for object in object_list %}
    {% include "subtemplate.html" %}
{% endfor %}

带有 subtemplate.html 的内容： 

{% cycle 'even' 'odd' %}

使用非线程安全的、Django 1.2 之前的渲染器，这将输出： 

even odd even odd ...

使用线程安全的 Django 1.2 渲染器，您将获得： 

even even even even ...

这是因为 :ttag:`include` 标签的每次渲染都是独立的渲染。 当 :ttag:`cycle` 标签不是线程安全的，:ttag:`cycle` 标签的状态会在同一个 :ttag 的多次渲染之间泄漏:`包括`。 现在 :ttag:`cycle` 标签是线程安全的，这种泄漏不再发生。


user_passes_test、login_required 和 permission_required

django.contrib.auth.decorators 提供了装饰器 login_required、permission_required 和 user_passes_test。 以前，可以在函数（第一个参数是“request”）和方法（第一个参数是“self”，第二个参数是“request”）上使用这些装饰器。 不幸的是，在支持此功能的代码中发现了缺陷：它仅在有限的情况下起作用，并且在不起作用时会产生很难调试的错误。

因此，“自动适应”行为已被删除，如果您在方法上使用这些装饰器，则需要手动应用 django.utils.decorators.method_decorator() 将装饰器转换为一种使用方法的方法。 例如，您可以更改以下代码： 

class MyClass(object):

    @login_required
    def my_view(self, request):
        pass

对此： 

from django.utils.decorators import method_decorator

class MyClass(object):

    @method_decorator(login_required)
    def my_view(self, request):
        pass

或者： 

from django.utils.decorators import method_decorator

login_required_m = method_decorator(login_required)

class MyClass(object):

    @login_required_m
    def my_view(self, request):
        pass

对于那些一直关注开发主干的人，此更改也适用于自 1.1 以来引入的其他装饰器，包括 csrf_protect、cache_control 以及使用 decorator_from_middleware 创建的任何内容。


:ttag:`if` 标签变化

由于 :ttag:`if` 模板标签中的新功能，它不再接受“and”、“or”和“not”作为有效的 变量 名称。 以前，这些字符串可以用作变量名。 现在，关键字状态总是被强制执行，模板代码如 {% if not %} 或 {% if and %} 将抛出 TemplateSyntaxError。 此外，in 是一个新关键字，因此在此标签中不是有效的变量名。


LazyObject

LazyObject 是一个未公开但经常使用的实用程序类，用于延迟包装未知类型的其他对象。

在 Django 1.1 及更早版本中，它以非标准方式处理自省，这取决于实现名为 get_all_members() 的公共方法的包装对象。 由于这很容易导致名称冲突，因此已更改为使用标准的 Python 内省方法，涉及 __members__ 和 __dir__()。

如果您在自己的代码中使用了 LazyObject 并为包装对象实现了 get_all_members() 方法，则需要进行一些更改：

首先，如果您的类对自省没有特殊要求（即您没有实现 __getattr__() 或其他允许正常机制无法发现的属性的方法），您可以简单地删除 get_all_members()方法。 LazyObject 上的默认实现会做正确的事情。

如果你有更复杂的内省需求，首先将get_all_members()方法重命名为__dir__()。 这是 Python 2.6 及更高版本的标准内省方法。 如果您需要支持 2.6 之前的 Python 版本，请将以下代码添加到类中： 

__members__ = property(lambda self: self.__dir__())

__dict__ 在模型实例上

历史上，模型实例的 __dict__ 属性仅包含与模型上的字段对应的属性。

为了支持多种数据库配置，Django 1.2 为对象实例添加了 _state 属性。 对于模型实例，此属性将出现在 __dict__ 中。 如果您的代码依赖于迭代 __dict__ 来获取字段列表，您现在必须准备好处理或过滤掉 _state 属性。


测试运行器退出状态码

测试运行程序（tests/runtests.py 和 python manage.py test）的退出状态代码不再代表失败测试的数量，因为 256 次或更多测试失败会导致错误的退出状态代码。 测试运行器的退出状态代码现在是 0 表示成功（没有失败的测试），1 表示任意数量的测试失败。 如果需要，可以在测试运行器输出的末尾找到测试失败的次数。


ModelForm.is_valid() 和 ModelForm.errors

ModelForms 的大部分验证工作已下移到模型级别。 因此，当您第一次调用 ModelForm.is_valid()、访问 ModelForm.errors 或以其他方式触发表单验证时，您的模型将被就地清理。 这种转换曾经在保存模型时发生。 如果您需要模型的未修改实例，则应将副本传递给 ModelForm 构造函数。


BooleanField 在 MySQL 上

在以前的 Django 版本中，MySQL 下模型的 BooleanField 将返回其值作为 1 或 0，而不是 True 或 False ]; 对于大多数人来说，这不是问题，因为 bool 是 Python 中 int 的子类。 然而，在 Django 1.2 中，MySQL 上的 BooleanField 正确返回了一个真正的 bool。 这应该成为问题的唯一时间是，如果您期望 BooleanField 的 repr 打印 1 或 0。


更改 FormSets 中 max_num 的解释

作为对 FormSet 处理进行增强的一部分，max_num 参数的默认值和解释为 django.forms.formsets.formset_factory() 和 django.forms。 models.modelformset_factory() 函数略有变化。 此更改还会影响 max_num 参数用于内联管理对象的方式。

以前，max_num 的默认值为 0（零）。 然后 FormSets 使用 max_num 的布尔值来确定是否对生成的表单数量施加限制。 0 的默认值意味着 FormSet 中的表单数量没有默认限制。

从 1.2 开始，max_num 的默认值已更改为 None，并且 FormSets 将区分 None 的值和 0 的值。 None 的值表示不限制表格的数量； 0 的值表示应施加最多 0 个表单。 这并不一定意味着不会显示任何表单 - 请参阅 ModelFormSet 文档 了解更多详细信息。

如果您手动为 max_num 指定值 0，您将需要更新您的 FormSet 和/或管理定义。

也可以看看

管理中内联相关对象的 JavaScript 辅助处理


email_re

用于验证电子邮件地址的未公开正则表达式已从 django.form.fields 移至 django.core.validators。 如果您正在使用它，您将需要更新您的导入。


1.2 中弃用的功能

最后，Django 1.2 弃用了早期版本中的一些功能。 这些功能仍受支持，但将在接下来的几个发布周期中逐步淘汰。

利用以下任何功能的代码将在 Django 1.2 中引发 PendingDeprecationWarning。 默认情况下，此警告是静默的，但可以使用 Python 的 warnings 模块打开，或者通过运行带有 -Wd 或 -Wall 标志的 Python。

在 Django 1.3 中，这些警告会变成 DeprecationWarning，也就是 not 静默。 在 Django 1.4 中，对这些特性的支持将被完全删除。

也可以看看

更多详细信息，请参阅文档 Django 的发布过程 和我们的 弃用时间表 。`


指定数据库

在 Django 1.2 之前，Django 使用许多设置来控制对单个数据库的访问。 Django 1.2 引入了对多个数据库的支持，因此您定义数据库设置的方式发生了变化。

任何现有的 Django 设置文件将继续按预期工作，直到 Django 1.4。 在此之前，旧式数据库设置将自动转换为新式格式。

在旧式（1.2 之前）格式中，您的设置文件中有许多 DATABASE_ 设置。 例如： 

DATABASE_NAME = 'test_db'
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_USER = 'myusername'
DATABASE_PASSWORD = 's3krit'

这些设置现在位于名为 :setting:`DATABASES` 的字典中。 字典中的每一项都对应一个单一的数据库连接，名称为 'default' 描述了默认的数据库连接。 设置名称也已缩短。 之前的示例设置现在看起来像这样： 

DATABASES = {
    'default': {
        'NAME': 'test_db',
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'USER': 'myusername',
        'PASSWORD': 's3krit',
    }
}

这会影响以下设置：

旧环境 新设置
数据库引擎 ：设置：`引擎 `
数据库主机 ：设置：`主机`
数据库名称 ：设置：`名称`
DATABASE_OPTIONS ：设置：`选项`
数据库密码 ：设置：`密码`
数据库端口 ：设置：`端口`
数据库用户 ：设置：`用户`
TEST_DATABASE_CHARSET ：设置：`TEST_CHARSET`
TEST_DATABASE_COLLATION ：设置：`TEST_COLLATION`
TEST_DATABASE_NAME ：设置：`TEST_NAME`

如果您使用 DatabaseWrapper() 从您选择的数据库后端手动创建了数据库连接，则也需要进行这些更改。

除了结构上的变化，Django 1.2 删除了对内置数据库后端的特殊处理。 所有数据库后端现在必须由完全限定的模块名称指定（即，django.db.backends.postgresql_psycopg2，而不仅仅是 postgresql_psycopg2）。


postgresql 数据库后端

psycopg1 库自 2005 年 10 月以来未更新。 因此，使用该库的 postgresql 数据库后端已被弃用。

如果您当前正在使用 postgresql 后端，则应迁移到使用 postgresql_psycopg2 后端。 要更新您的代码，请安装psycopg2库并更改 ：设置：`引擎 ` 要使用的设置django.db.backends.postgresql_psycopg2 .


CSRF 响应重写中间件

CsrfResponseMiddleware，自动将 CSRF 令牌插入到传出页面的 POST 表单中的中间件，已被弃用，取而代之的是模板标记方法（见上文），并将在 Django 1.4 中完全删除。 CsrfMiddleware 包括 CsrfResponseMiddleware 和 CsrfViewMiddleware 的功能，同样已被弃用。

此外，CSRF 模块已从 contrib 移动到核心，并且不推荐使用旧的导入，如升级说明中所述。

文档已删除

升级说明已在当前 Django 文档中删除。 请参阅 Django 1.3 或更早版本的文档以查找这些说明。


SMTPConnection

SMTPConnection 类已被弃用，取而代之的是通用电子邮件后端 API。 显式实例化 SMTPConnection 实例的旧代码： 

from django.core.mail import SMTPConnection
connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)

...现在应该调用 get_connection() 来实例化一个通用的电子邮件连接： 

from django.core.mail import get_connection
connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)

根据 :setting:`EMAIL_BACKEND` 设置的值，这可能不会返回 SMTP 连接。 如果您明确要求使用 SMTP 连接来发送电子邮件，则可以明确请求 SMTP 连接： 

from django.core.mail import get_connection
connection = get_connection('django.core.mail.backends.smtp.EmailBackend')
messages = get_notification_email()
connection.send_messages(messages)

如果您调用构造 SMTPConnection 的实例需要附加参数，则可以将这些参数传递给 get_connection() 调用： 

connection = get_connection('django.core.mail.backends.smtp.EmailBackend', hostname='localhost', port=1234)

用户消息 API

用于在用户 Message 模型中存储消息的 API（通过 user.message_set.create）现已弃用，并将根据标准 发布过程 在 Django 1.4 中删除。

要升级您的代码，您需要替换以下任何实例： 

user.message_set.create('a message')

...具有以下内容： 

from django.contrib import messages
messages.add_message(request, messages.INFO, 'a message')

此外，如果使用该方法，则需要替换以下内容： 

for message in user.get_and_delete_messages():
    ...

…和： 

from django.contrib import messages
for message in messages.get_messages(request):
    ...

有关更多信息，请参阅完整的 消息文档 。 您应该立即开始更新代码以使用新 API。


日期格式辅助函数

django.utils.translation.get_date_formats() 和 django.utils.translation.get_partial_date_formats() 已被弃用，取而代之的是对 django.utils.formats.get_format() 的适当调用，当设置 :setting:`USE_L10N` 时，它可以识别区域设置到 True，如果设置为 False，则回退到默认设置。

要获得不同的日期格式，而不是这样写： 

from django.utils.translation import get_date_formats
date_format, datetime_format, time_format = get_date_formats()

…用： 

from django.utils import formats
date_format = formats.get_format('DATE_FORMAT')
datetime_format = formats.get_format('DATETIME_FORMAT')
time_format = formats.get_format('TIME_FORMAT')

或者，当直接格式化日期值时： 

from django.utils import formats
value_formatted = formats.date_format(value, 'DATETIME_FORMAT')

这同样适用于 django.forms.fields 中的全局变量：

  • DEFAULT_DATE_INPUT_FORMATS
  • DEFAULT_TIME_INPUT_FORMATS
  • DEFAULT_DATETIME_INPUT_FORMATS

使用 django.utils.formats.get_format() 获取适当的格式。


基于函数的测试运行器

Django 1.2 将测试运行器工具更改为使用基于类的方法。 旧式基于函数的测试运行器仍然可以工作，但应该更新以使用新的 基于类的运行器 。


Feed 在 django.contrib.syndication.feeds

django.contrib.syndication.feeds.Feed 类已被 django.contrib.syndication.views.Feed 类取代。 旧的 feeds.Feed 类已弃用，并将在 Django 1.4 中删除。

新类具有几乎相同的 API，但允许将实例用作视图。 例如，考虑使用以下 URLconf 中的旧框架： 

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

feeds = {
    'latest': LatestEntries,
    'categories': LatestEntriesByCategory,
}

urlpatterns = patterns('',
    # ...
    (r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',
        {'feed_dict': feeds}),
    # ...
)

使用新的 Feed 类，这些提要可以直接部署为视图： 

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

urlpatterns = patterns('',
    # ...
    (r'^feeds/latest/$', LatestEntries()),
    (r'^feeds/categories/(?P<category_id>\d+)/$', LatestEntriesByCategory()),
    # ...
)

如果您当前使用 feed() 视图，除了继承新的 Feed 类之外，通常不需要修改 LatestEntries 类。 例外情况是，如果 Django 自动计算出用于呈现提要的描述和标题元素的模板名称（如果您没有指定 title_template 和 description_template 属性）。 您应该确保始终指定 title_template 和 description_template 属性，或提供 item_title() 和 item_description() 方法。

但是，LatestEntriesByCategory 使用 get_object() 方法和 bits 参数来指定要显示的特定类别。 在新的 Feed 类中，get_object() 方法从 URL 获取 request 和参数，所以它看起来像这样： 

from django.contrib.syndication.views import Feed
from django.shortcuts import get_object_or_404
from myproject.models import Category

class LatestEntriesByCategory(Feed):
    def get_object(self, request, category_id):
        return get_object_or_404(Category, id=category_id)

    # ...

此外，Feed 类上的 get_feed() 方法现在采用不同的参数，如果您直接使用 Feed 类，这可能会影响您。 它不再只采用可选的 url 参数，而是采用两个参数：由其自己的 get_object() 方法返回的对象和当前的 request 对象。

考虑到 Feed 类没有为每个请求初始化，__init__() 方法现在默认不接受任何参数。 以前它会从 URL 和 request 对象中获取 slug。

根据 RSS 最佳实践 ，RSS 提要现在将包含 atom:link 元素。 您可能需要更新您的测试以将其考虑在内。

有关更多信息，请参阅完整的 联合框架文档 。


技术消息 ID

在 1.1 版本之前，Django 使用技术消息 ID 为本地化人员提供翻译日期和时间格式的可能性。 它们是可翻译的 翻译字符串 可以识别，因为它们都是大写的（例如 :setting:`DATETIME_FORMAT`、:setting:`DATE_FORMAT`、 ：设置：`TIME_FORMAT`)。 它们已被弃用，取而代之的是新的 格式本地化 基础结构，该基础结构允许本地化人员在相应的 django/conf/locale/<locale name>/ 目录中的 formats.py 文件中指定该信息。


吉奥姜戈

为了支持多个数据库，GeoDjango 数据库内部结构发生了重大变化。 最大的向后不兼容变化是模块 django.contrib.gis.db.backend 被重命名为 django.contrib.gis.db.backends，其中成熟的 空间数据库后端 现在存在。 以下部分提供有关受这些更改影响的最流行 API 的信息。

SpatialBackend

在创建单独的空间后端之前，提供了 django.contrib.gis.db.backend.SpatialBackend 对象作为对空间数据库功能进行内省的抽象。 SpatialBackend 提供的所有属性和例程现在都是数据库后端 ops 属性的一部分。

旧模块 django.contrib.gis.db.backend 仍然提供对 SpatialBackend 对象的向后兼容访问，它只是 default 的 ops 模块的别名空间数据库连接。

依赖 django.contrib.gis.db.backend 中未记录的模块和对象而不是 SpatialBackend 提供的抽象的用户需要修改他们的代码。 例如，以下导入适用于 1.1 及以下版本： 

from django.contrib.gis.db.backend.postgis import PostGISAdaptor

将需要更改： 

from django.db import connection
PostGISAdaptor = connection.ops.Adapter

SpatialRefSys 和 GeometryColumns 型号

在以前版本的 GeoDjango 中，django.contrib.gis.db.models 有 SpatialRefSys 和 GeometryColumns 模型用于查询 OGC 空间元数据表 spatial_ref_sys 和geometry_columns，分别。

虽然仍然提供这些别名，但它们仅用于 default 数据库连接，并且仅当默认连接使用受支持的空间数据库后端时才存在。

笔记

由于 OGC 空间元数据表的表结构因空间数据库而异，因此 SpatialRefSys 和 GeometryColumns 模型无法再与 gis 应用程序名称相关联。 因此，在以下示例中使用 get_models 方法时不会返回任何模型： 

>>> from django.db.models import get_app, get_models
>>> get_models(get_app('gis'))
[]

要为您的空间数据库获取正确的 SpatialRefSys 和 GeometryColumns，请使用空间后端提供的方法： 

>>> from django.db import connections
>>> SpatialRefSys = connections['my_spatialite'].ops.spatial_ref_sys()
>>> GeometryColumns = connections['my_postgis'].ops.geometry_columns()

笔记

使用从 spatial_ref_sys() 和 geometry_columns() 方法返回的模型时，在非默认连接上查询时仍需要使用正确的数据库别名。 换句话说，要确保上面示例中的模型使用正确的数据库： 

sr_qs = SpatialRefSys.objects.using('my_spatialite').filter(...)
gc_qs = GeometryColumns.objects.using('my_postgis').filter(...)

语言代码 no

挪威语 Bokmål no 目前使用的语言代码正在被更常用的语言代码 nb 取代。


基于函数的模板加载器

Django 1.2 将模板加载机制更改为使用基于类的方法。 旧式基于函数的模板加载器仍然可以工作，但应该更新以使用新的基于类的模板加载器。



取自“https://cainiaojiaocheng.com/index.php?title=Django/docs/2.2.x/releases/1.2&oldid=20398”
Powered by MediaWiki