2010年5月17日
欢迎来到Django 1.2！
近一年来，Django 1.2包含了令人印象深刻的新功能列表和大量的错误修复。这些发行说明介绍了新功能，以及从Django 1.1或旧版本升级时需要注意的重要更改。
Django 1.2引入了几个大的，重要的新功能，包括：
这些只是亮点；完整详细信息和功能的完整列表可在下面找到。
也可以看看
Django Advent涵盖了一系列文章和教程，涵盖了一些深入的新功能的Django 1.2版本。
在可能的情况下，根据our API stability policy策略，这些功能以向后兼容的方式引入。
但是，的一些功能已更改，对于某些用户，将向后不兼容。最大的变化是：
支持Python 2.3已被删除。请参阅下面的完整注释。
新的CSRF保护框架不向后兼容旧系统。旧系统的用户将不会受到影响，直到旧系统在Django 1.4中删除。
但是，升级到新的CSRF保护框架需要一些重要的向后不兼容的更改，详情请参见CSRF保护。
自定义Field子类的作者应该知道，许多方法在原型中发生了变化，详细信息请参见下面的字段上的get_db_prep _ *()方法。
模板标签的内部有所改变；需要存储状态的定制模板标签的作者。自定义控制流标记）应确保其代码遵循状态模板标记的新规则
The user_passes_test(), login_required(), and permission_required(), decorators from django.contrib.auth only apply to functions and no longer work on methods. 下面有一个简单的单行修复。
同样，这些只是影响大多数用户的大功能。强烈鼓励从以前版本的Django升级的用户查阅backwards-incompatible changes和deprecated features列表的完整列表。
虽然不是一个新的功能，但重要的是要注意，Django 1.2引入了我们的Python兼容性政策的第一个变化，因为Django的初次公开亮相。以前的Django版本测试和支持2.x Python版本从2.3起； 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，直到你可以升级；根据our support policy，Django 1.1将继续接收安全支持，直到发布Django 1.3。
Django整体2.x Python支持和最终转换到Python 3.x的路线图目前正在开发中，并将在发布Django 1.3之前公布。
Django 1.2添加了在Django项目中使用more than one database的功能。可以使用QuerySet对象上的using()方法在特定数据库中发出查询。当您调用save()时，通过提供using参数，可将单个对象保存到特定数据库。
模型实例现在支持validating their own data，并且模型和表单字段现在接受validators的可配置列表，指定可重用的，封装的验证行为。但是，请注意，验证仍然必须明确执行。简单地调用模型实例的save()方法不会对实例的数据执行任何验证。
Django现在对Cross-Site Request Forgery (CSRF) attacks有更多的保护。当恶意网站包含链接，表单按钮或某些JavaScript（旨在使用在其浏览器中访问恶意网站的已登录用户的凭据在您的网站上执行某些操作）时，会发生此类型的攻击。还涉及相关类型的攻击“登录CSRF”，其中攻击站点欺骗用户的浏览器登录具有他人的凭证的站点。
Django现在包括一个强大且可配置的messages framework，内置支持基于Cookie和基于会话的消息传递，无论匿名客户端还是经过身份验证的客户端。消息框架替换已弃用的用户消息API，并允许您将消息临时存储在一个请求中，并检索它们以便在后续请求（通常是下一个请求）中显示。
添加了在每个对象级别指定权限的基础。虽然在核心没有实现这一点，自定义认证后端可以提供这个实现，它将由django.contrib.auth.models.User使用。有关详细信息，请参阅authentication docs。
如果您提供自定义验证后端supports_anonymous_user设置为True，则AnonymousUser将像后者一样检查后端的权限。这对于集中权限处理很有用 - 应用程序总是可以将授权/身份验证后端是否允许某些东西的问题委托给他人。有关详细信息，请参阅authentication docs。
The built-in User model’s username field now allows a wider range of characters, including @, +, .和-字符。
您现在可以configure the way that Django sends email。您可以选择可配置的电子邮件后端来发送邮件，而不是使用SMTP发送所有电子邮件。如果您的托管提供商使用沙箱或其他非SMTP技术发送邮件，则现在可以构建一个电子邮件后端，以便允许Django的标准mail sending methods使用这些设施。
这也使得更容易调试邮件发送。Django附带了后端实现，允许您向file，console或memory发送电子邮件。您甚至可以将所有电子邮件配置为thrown away。
if标记已升级为更强大。首先，我们增加了对比较运算符的支持。您不再需要键入：
{% ifnotequal a b %}
...
{% endifnotequal %}
你现在可以这样做：
{% if a != b %}
...
{% endif %}
没有理由使用{％ ifequal ％}或{％ t5> ifnotequal ％}，除非你是怀旧的类型。
The operators supported are ==, !=, <, >, <=, >=, in and not in, all of which work like the Python operators, in addition to and, or and not, which were already supported.
此外，现在可以在if表达式中使用过滤器。例如：
<div
{% if user.email|lower == message.recipient|lower %}
class="highlight"
{% endif %}
>{{ message }}</div>
在以前的Django版本中，每次渲染模板时，都会从磁盘重新加载。在Django 1.2中，您可以使用cached template loader加载模板一次，然后缓存每个后续渲染的结果。如果您的模板被分成许多较小的子模板（使用{％ extend ％} 或{％ include ％}
作为副作用，现在更容易支持非Django模板语言。
作为对引入模板缓存所做的更改的一部分，并遵循Django中的一般趋势，模板加载器API已修改为使用模板加载机制，这些加载机制封装在Python类中，而不是函数，方法可用，直到Django 1.1。
All the template loaders shipped with Django have been ported to the new API but they still implement the function-based API and the template core machinery still accepts function-based loaders (builtin or third party) so there is no immediate need to modify your TEMPLATE_LOADERS setting in existing projects, things will keep working if you leave it untouched up to and including the Django 1.3 release.
如果您已经开发了自己的自定义模板加载器，我们建议考虑将它们移植到基于类的实现，因为与基于函数的加载器向后兼容的代码在Django 1.2中开始其弃用过程，并将在Django 1.4中删除。这些加载器类必须在模板API引用中实现的API描述，您还可以检查Django附带的加载器的源代码。
Fixtures现在可以使用Natural keys来引用远程对象。此查找方案是夹具中基于正常基于主键的对象引用的替代方案，提高了可读性并解决了引用其主键值不可预测或已知的对象的问题。
用于运行Django自己的测试套件的django-admin.py的test子命令和runtests.py脚本现在支持--failfast选项。指定时，此选项将导致测试运行程序在遇到故障后退出，而不是继续测试运行。此外，在测试运行期间对Ctrl-C的处理已得到改进，以触发从测试运行中正常退出，报告在中断之前运行的测试的详细信息。
模型现在可以使用64位BigIntegerField类型。
Django的internationalization framework已经扩展了语言环境感知格式和表单处理。这意味着，如果启用，模板上的日期和数字将使用为当前语言环境指定的格式显示。在解析表单中的数据时，Django还将使用本地化格式。有关详细信息，请参阅Format localization。
已添加django.contrib.admin.ModelAdmin.readonly_fields以在模型和内联的添加/更改页面中启用不可编辑的字段。字段和计算值可以与可编辑字段一起显示。
现在，您可以使用DJANGO_COLORS环境变量修改或禁用django-admin.py使用的颜色，以提供syntax highlighting。
Syndication feeds现在可以直接用作您的URLconf中的视图。这意味着您可以完全控制Feed的网址结构。与任何其他视图一样，Feed视图传递了一个request对象，因此您可以对视图执行任何操作，例如基于用户的访问控制，或者使某个Feed成为一个命名的网址。
1.2中的GeoDjango的最重要的新功能是支持多个空间数据库。因此，现在包括以下spatial database backends：
GeoDjango现在支持PostGIS 1.5版本中添加的丰富功能。新功能包括支持geography type并启用在地理坐标系上使用非点几何的distance queries。
添加了对3D几何字段的支持，并且可以通过在GeometryField中将dim关键字设置为3来启用。作为此功能的一部分，添加了Extent3D聚合和extent3d() GeoQuerySet方法。
以下GeoQuerySet方法是1.2中新增的：
更新了GEOS接口以在平台上可用时使用线程安全的C库函数。
现在，GDAL接口允许用户在迭代Layer时返回的要素上设置spatial_filter。
最后，GeoDjango’s documentation现在包含在Django中，不再单独托管在geodjango.org。
now的参数已获得两个新的格式字符：c以指定日期时间值应格式化为ISO 8601格式，u允许输出微秒部分的日期时间或时间值。
These are also available in others parts like the date and time template filters, the humanize template tag library and the new format localization framework.
在可能的情况下，我们的API稳定性策略政策中已经按照our API stability policy这意味着几乎所有使用Django 1.1的现有代码都将继续使用Django 1.2；但是，这样的代码将开始发出警告（详见下文）。
但是，的某些功能已更改，对于某些用户，将立即反向不兼容。这些更改详细如下。
我们对CSRF保护的工作方式进行了重大更改，详情请参见the CSRF documentation。以下是您应该注意的主要变化：
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）。
在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中，这三种方法经历了原型的改变，并引入了两种额外的方法：
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定义，以尽快使用新的原型。
If your get_db_prep_*() methods made no use of the database connection, you should be able to upgrade by renaming get_db_prep_value() to get_prep_value() and get_db_prep_lookup() to get_prep_lookup(). 如果需要特定于数据库的转换，则需要提供使用connection参数的实现get_db_prep_*来解析特定于数据库的值。
在Node子类上存储呈现状态的模板标签一直易受线程安全性和其他问题的影响；但是，当使用新的cached template loader时，它们也可能会导致问题。
所有内置的Django模板标签都可以安全地用于缓存加载器，但如果您使用来自第三方包或来自您自己的代码的自定义模板标签，则应确保Node有关详细信息，请参阅template tag thread safety considerations。
如果您依赖于执行Django的模板标记而不是是线程安全的，您可能还需要更新模板。cycle标记最有可能以此方式受到影响，特别是与include标记结合使用时。考虑以下模板片段：
{% for object in object_list %}
{% include "subtemplate.html" %}
{% endfor %}
使用subtemplate.html：
{% cycle 'even' 'odd' %}
使用非线程安全的，pre-Django 1.2渲染器，这将输出：
even odd even odd ...
使用线程安全的Django 1.2渲染器，你会得到：
even even even even ...
这是因为include标签的每个渲染都是独立渲染。当cycle标记不是线程安全时，cycle标记的状态将在同一include的多个呈现之间泄漏。现在cycle标记是线程安全的，这种泄漏不再发生。
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。
由于if模板标记中的新功能，它不再接受“and”，“or”和“not”作为有效的变量名称。以前，这些字符串可以用作变量名。Now, the keyword status is always enforced, and template code such as {% if not %} or {% if and %} will throw a TemplateSyntaxError. 此外，in中是一个新关键字，因此在此标记中不是有效的变量名称。
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__属性仅包含与模型上的字段对应的属性。
为了支持多个数据库配置，Django 1.2为对象实例添加了一个_state属性。此属性将出现在模型实例的__dict__中。如果您的代码依赖于遍历__dict__以获取字段列表，您现在必须准备好处理或过滤出_state属性。
测试运行者的退出状态代码（tests/runtests.py和python manage.py test t5 >）不再表示失败的测试的数量，因为256个或更多测试的失败导致错误的退出状态代码。测试运行器的退出状态代码现在为0表示成功（无失败测试），1表示任意数量的测试失败。如果需要，在测试运行器输出结束时可以发现测试失败的次数。
To fix bugs with cookies in Internet Explorer, Safari, and possibly other browsers, our encoding of cookie values was changed so that the comma and semicolon are treated as non-safe characters, and are therefore encoded as \054 and \073 respectively. 这可能会产生向后不兼容，特别是如果你在cookie中存储逗号或分号，并且有JavaScript代码来解析和操纵cookie值客户端。
ModelForms的大部分验证工作已经向下移动到模型级别。因此，第一次调用ModelForm.is_valid()，访问ModelForm.errors或以其他方式触发表单验证时，模型将被原位清除。此转换过去是在保存模型时发生的。如果您需要模型的未修改实例，则应将副本传递给ModelForm构造函数。
In previous versions of Django, a model’s BooleanField under MySQL would return its value as either 1 or 0, instead of True or False; for most people this wasn’t a problem because bool is a subclass of int in Python. 但是，在Django 1.2中，MySQL上的BooleanField正确地返回一个真实的bool。如果你期望BooleanField的repr打印1或0
作为对FormSet的处理的一部分，将max_num参数到django.forms.formsets.formset_factory()和django.forms.models.modelformset_factory()函数略有更改。此更改还会影响max_num参数用于内联管理对象的方式。
以前，max_num的默认值为0（零）。然后，FormSet使用max_num的布尔值来确定是否对生成的表单数量施加了限制。默认值0意味着FormSet中的表单数量没有默认限制。
Starting with 1.2, the default value for max_num has been changed to None, and FormSets will differentiate between a value of None and a value of 0. 值None表示不对表格数量施加任何限制；值0表示应当施加最多0个形式。这并不一定意味着不会显示任何表单 - 有关详细信息，请参阅ModelFormSet documentation。
如果您为max_num手动指定值0，则需要更新您的FormSet和/或管理员定义。
用于验证电子邮件地址的未记录的正则表达式已从django.form.fields移至django.core.validators。如果您使用导入，则需要更新导入。
最后，Django 1.2弃用了早期版本的一些功能。这些功能仍然受支持，但将在接下来的几个发布周期中逐步淘汰。
利用以下任何功能的代码将在Django 1.2中生成PendingDeprecationWarning。默认情况下，此警告将保持沉默，但可以使用Python的warnings模块打开，或者使用-Wd或-Wall旗。
在Django 1.3中，这些警告将变成DeprecationWarning，这是不是沉默。在Django 1.4中对这些功能的支持将被完全删除。
也可以看看
有关详细信息，请参阅文档Django’s release process和我们的deprecation timeline。
在Django 1.2之前，Django使用了许多设置来控制对单个数据库的访问。Django 1.2引入了对多个数据库的支持，因此，您定义数据库设置的方式已更改。
任何现有的Django设置文件将继续正常工作，直到Django 1.4。在此之前，旧式数据库设置将自动转换为新式格式。
在旧式（pre 1.2）格式中，您的设置文件中有一些DATABASE_设置。例如：
DATABASE_NAME = 'test_db'
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_USER = 'myusername'
DATABASE_PASSWORD = 's3krit'
这些设置现在位于名为DATABASES的字典中。字典中的每个项目对应于单个数据库连接，名称为'default'描述默认数据库连接。设置名称也已缩短。之前的样本设置现在看起来像这样：
DATABASES = {
'default': {
'NAME': 'test_db',
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'USER': 'myusername',
'PASSWORD': 's3krit',
}
}
这会影响以下设置：
| 旧的设置 | 新设置 |
|---|---|
| DATABASE_ENGINE | ENGINE |
| DATABASE_HOST | HOST |
| DATABASE_NAME | NAME |
| DATABASE_OPTIONS | OPTIONS |
| DATABASE_PASSWORD | PASSWORD |
| DATABASE_PORT | PORT |
| DATABASE_USER | USER |
| TEST_DATABASE_CHARSET | TEST_CHARSET |
| TEST_DATABASE_COLLATION | TEST_COLLATION |
| TEST_DATABASE_NAME | TEST_NAME |
如果您已从所选的数据库后端使用DatabaseWrapper()手动创建数据库连接，则这些更改也是必需的。
除了结构的改变，Django 1.2删除了内置数据库后端的特殊处理。All database backends must now be specified by a fully qualified module name (i.e., django.db.backends.postgresql_psycopg2, rather than just postgresql_psycopg2).
psycopg1库自2005年10月以来未更新。因此，已弃用使用此库的postgresql数据库后端。
如果您目前正在使用postgresql后端，则应该使用postgresql_psycopg2后端。要更新代码，请安装psycopg2库并更改ENGINE设置以使用django.db.backends.postgresql_psycopg2。
CsrfResponseMiddleware是自动将CSRF令牌插入到传出页面中的POST表单中的中间件，已被弃用，支持模板标记方法（见上文），并将完全删除在Django 1.4。包括CsrfResponseMiddleware和CsrfViewMiddleware的功能的CsrfMiddleware也已被弃用。
此外，CSRF模块已从contrib转移到core，旧的导入已被弃用，如升级说明中所述。
文档已删除
升级说明已在当前的Django文档中删除。请参阅Django 1.3或更旧版本的文档以查找这些说明。
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)
根据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)
用于在用户Message模型（通过user.message_set.create）存储消息的API现已废弃，并将根据标准release process。
要升级代码，您需要替换以下任何实例：
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):
...
有关详细信息，请参阅完整的messages documentation。您应该立即更新代码以使用新的API。
django.utils.translation.get_date_formats()和django.utils.translation.get_partial_date_formats()已被弃用，以便适当调用django.utils.formats.get_format()，当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中找到的全局变量：
使用django.utils.formats.get_format()获取相应的格式。
Django 1.2改变了测试运行器工具以使用基于类的方法。旧样式的基于功能的测试跑者仍然可以工作，但应该更新以使用新的class-based runners。
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类，这些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自动计算出用于渲染Feed描述和标题元素的模板名称（如果您未指定title_template和description_template属性） 。您应确保始终指定title_template和description_template属性，或提供item_title()和item_description()方法。
但是，LatestEntriesByCategory使用get_object()方法和bits参数来指定要显示的特定类别。在新的Feed类中，get_object()方法从网址中获取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 feeds现在将包含一个atom:link元素。您可能需要更新测试，以考虑到这一点。
有关详细信息，请参阅完整的syndication framework documentation。
到1.1版Django使用技术消息ID为本地化者提供了翻译日期和时间格式的可能性。他们可翻译的translation strings可以被识别，因为它们都是大写（例如DATETIME_FORMAT，DATE_FORMAT，TIME_FORMATThey have been deprecated in favor of the new Format localization infrastructure that allows localizers to specify that information in a formats.py file in the corresponding django/conf/locale/<locale name>/ directory.
为了支持多个数据库，GeoDjango数据库内部实际上发生了变化。最大的向后不兼容的更改是模块django.contrib.gis.db.backend已重命名为django.contrib.gis.db.backends，其中，成熟的spatial database backends现在存在。以下部分提供受这些更改影响的最受欢迎API的信息。
在创建单独的空间后端之前，提供django.contrib.gis.db.backend.SpatialBackend对象作为抽象以对空间数据库的功能进行内省。SpatialBackend提供的所有属性和例程现在都是数据库后端的ops属性的一部分。
The old module django.contrib.gis.db.backend is still provided for backwards-compatibility access to a SpatialBackend object, which is just an alias to the ops module of the default spatial database connection.
依赖于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
在之前版本的GeoDjango中，django.contrib.gis.db.models具有用于查询OGC空间元数据表的SpatialRefSys和GeometryColumns模型spatial_ref_sys和geometry_columns。
虽然仍然提供这些别名，但它们仅用于默认数据库连接，并且仅当默认连接使用受支持的空间数据库后端时才存在。
注意
由于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(...)
挪威语Bokmålno的当前使用的语言代码正被更常见的语言代码nb替换。
Django 1.2改变了模板加载机制以使用基于类的方法。基于旧样式函数的模板加载器仍然可以工作，但应该更新以使用新的基于类的模板加载器。
2015年5月13日