Django 1.1 release notes

2009年7月29日

欢迎来到Django 1.1！

Django 1.1包括一些漂亮的新功能，大量的错误修复，以及从Django 1.0的简单升级路径。

Backwards-incompatible changes in 1.1

Django的政策是API stability。这意味着，一般来说，你针对Django 1.0开发的代码应该继续工作对1.1不变。但是，如果有必要解决错误，我们有时会进行向后不兼容的更改，并且Django 1.0和Django 1.1之间有一些（小的）更改。

在升级到Django 1.1之前，您应该仔细检查以下更改不会对您造成影响，如果有，请升级您的代码。

Changes to constraint names

Django 1.1修改用于生成数据库约束名称的方法，以使名称一致，而不考虑机器字大小。此更改对于某些用户向后不兼容。

如果你使用的是32位的平台，您将没有观察到此更改的结果的差异。

但是，使用reset管理命令，64位平台上的用户可能会遇到一些问题。在此更改之前，64位平台将在约束名称中生成一个64位，16个字符的摘要；例如：

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...

在此更改之后，所有平台，无论字大小，将在约束名称中生成一个32位，8个字符的摘要；例如：

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...

作为此更改的结果，您将无法对64位计算机上的任何表使用reset管理命令。这是因为新生成的名称将不匹配历史生成的名称；因此，由reset命令构造的SQL将无效。

如果需要重置使用64位约束创建的应用程序，则需要在调用reset之前手动删除旧的约束。

Test cases are now run in a transaction

Django 1.1在事务中运行测试，以提高测试性能（有关详细信息，请参阅测试性能改进）。

如果现有测试需要测试事务行为，如果它们依赖关于测试环境的无效假设，或者如果它们需要特定的测试用例排序，则此更改略微向后不兼容。

对于这些情况，可以改用TransactionTestCase。这是一个快速修复，以解决新的回滚方法显示的测试用例错误；在长期测试中应该重写以纠正测试用例。

Removed SetRemoteAddrFromForwardedFor middleware

For convenience, Django 1.0 included an optional middleware class – django.middleware.http.SetRemoteAddrFromForwardedFor – which updated the value of REMOTE_ADDR based on the HTTP X-Forwarded-For header commonly set by some proxy configurations.

已经证明，这种机制不能足够可靠地用于通用目的，并且（尽管文档相反）将其包括在Django中可以使得应用开发者假设REMOTE_ADDR的值是“安全”或以某种方式可靠地作为认证源。

虽然不是直接的安全问题，我们决定删除这个中间件与Django 1.1版本。它已被替换为一个类，除了raise a DeprecationWarning。

如果你一直依赖这个中间件，最简单的升级路径是：

  • 检查代码在删除之前的存在。
  • 验证它与您的上游代理正常工作，修改它以支持您的特定代理（如果必要）。
  • 将您的修改版本SetRemoteAddrFromForwardedFor介绍为您自己项目中的一个中间件。

Names of uploaded files are available later

在Django 1.0中，上传并存储在模型的FileField中的文件在将模型保存到数据库之前已保存到磁盘。这意味着分配给文件的实际文件名在保存前可用。例如，它在模型的预保存信号处理程序中可用。

在Django 1.1中，文件被保存为数据库中保存模型的一部分，因此在保存模型之后之前，不能依赖磁盘上使用的实际文件名。

Changes to how model formsets are saved

在Django 1.1中，BaseModelFormSet现在调用ModelForm.save()。

如果您在模型表单集的__init__中修改self.initial，或者如果您依赖于内部_total_form_count或_initial_form_count属性。这些属性现在是公共方法。

Fixed the join filter’s escaping behavior

join过滤器不再转义为连接器传递的文字值。

这对于包含五个特殊HTML字符之一的文字字符串的特殊情况向后不兼容。因此，如果您正在撰写{{ foo | join：“＆amp；” }} 写入{{ foo | join：“＆amp； amp；” }}。

以前的行为是一个错误，与记录和预期相反。

Permanent redirects and the redirect_to() generic view

Django 1.1在django.views.generic.simple.redirect_to()视图中添加了permanent参数。如果您使用具有称为“permanent”的格式字符串键的redirect_to视图，这在技术上是向后不兼容的，这是不太可能的。

Features deprecated in 1.1

一个功能在Django 1.1中已标记为已弃用：

  • 您不应再使用AdminSite.root()注册该管理视图。也就是说，如果您的URLconf包含以下行：

    (r'^admin/(.*)', admin.site.root),

    您应该将其更改为：

    (r'^admin/', include(admin.site.urls)),

您应该立即从代码中删除使用此功能。

AdminSite.root会在Django 1.1中使用PendingDeprecationWarning。默认情况下隐藏此警告。在Django 1.2中，此警告将升级为DeprecationWarning，将大声显示。Django 1.3将完全删除AdminSite.root()。

有关我们的弃用政策和策略的详情，请参阅Django’s release process。

What’s new in Django 1.1

有一点：自Django 1.0以来，我们已经做了1,290个代码提交，修复了1,206个错误，并增加了大约10,000行文档。

Django 1.1中的主要新功能有：

ORM improvements

Django的对象关系映射器（ORM）增加了两个主要的增强功能：聚合支持和查询表达式。

Aggregate support

现在可以运行SQL聚合查询（即COUNT()，MAX()，MIN()等）从Django的ORM。您可以选择直接返回聚合结果，也可以在QuerySet中使用聚合查询的结果注释对象。

此功能可作为新的aggregate()和annotate()方法使用，并在the ORM aggregation documentation中详细介绍。

Query expressions

查询现在可以引用查询上的另一个字段，并可以遍历关系以引用相关模型上的字段。这在新的F对象中实现；有关详细信息（包括示例），请参阅F expressions documentation。

Model improvements

Django的模型层添加了许多功能：

“Unmanaged” models

现在，您可以使用managed模型选项控制Django是否管理模型的数据库表的生命周期。默认为True，这意味着Django将在syncdb中创建相应的数据库表，并将其作为reset命令的一部分删除。也就是说，Django 管理数据库表的生命周期。

但是，如果将此设置为False，则不会为此模型自动执行数据库表创建或删除。如果模型表示已由某些其他方法创建的现有表或数据库视图，这将非常有用。

有关详细信息，请参阅managed选项的文档。

Proxy models

现在，您可以创建proxy models：现有模型的子类，只添加Python级别（而不是数据库级别）行为，而不是由新表格表示。也就是说，新模型是用于存储所有真实数据的一些基础模型的代理。

所有详细信息均可在proxy models documentation中找到。这个特性在表面上类似于非托管模型，因此文档解释了how proxy models differ from unmanaged models。

Deferred fields

在某些复杂的情况下，您的模型可能包含可能包含大量数据（例如，大文本字段）的字段，或者需要昂贵的处理才能将它们转换为Python对象。如果你知道你不需要这些特定的字段，你现在可以告诉Django不要从数据库中检索它们。

您将使用新的查询集方法defer()和only()来实现此目的。

Testing improvements

对testing framework进行了一些显着的改进。

Test performance improvements

使用Django的testing framework写入的测试现在运行得更快（在许多情况下快10倍）。

这是通过引入基于事务的测试来实现的：当使用django.test.TestCase时，您的测试现在将在完成后回滚的事务中运行，而不是通过刷新和重新运行，填充数据库。这导致大多数类型的单元测试的极大的加速。有关完整说明和有关数据库支持的一些重要说明，请参阅TestCase和TransactionTestCase的文档。

Test client improvements

对测试客户端进行了一些小但是非常有用的改进：

  • The test Client now can automatically follow redirects with the follow argument to Client.get() and Client.post(). 这使测试视图发出重定向更简单。
  • 现在更容易在响应中返回测试客户端的模板上下文：您只需访问上下文request.context[key]。旧方法将request.context视为上下文列表，对于继承链中的每个已渲染模板，它仍然可用，如果您需要的话。

New admin features

Django 1.1为Django的管理界面添加了一些漂亮的新功能：

Editable fields on the change list

现在，您可以通过新的list_editable管理选项在管理列表视图中修改字段。这些字段将在列表页面上显示为表单小部件，并且可以批量编辑和保存。

Admin “actions”

您现在可以定义admin actions，可以批量对一组模型执行某些操作。用户可以在更改列表页面上选择对象，然后将这些批量操作应用于所有选定的对象。

Django附带一个预定义的管理操作，以一次删除一组对象。

Conditional view processing

Django现在对使用标准ETag和Last-Modified HTTP标头的conditional view processing有更好的支持。这意味着您现在可以通过测试成本较低的条件，轻松地短路视图处理。对于许多视图，这可以导致速度的显着改善和带宽的减少。

URL namespaces

Django 1.1通过引入URL“namespaces”来改进named URL patterns。

简而言之，此功能允许来自同一应用程序的同一组网址多次包含在Django URLConf中，并具有在执行反向解析时将使用的变化（可能嵌套）命名的前缀。换句话说，可重用的应用程序，如Django的管理界面可能会注册多次，没有URL冲突。

有关完整的详细信息，请参阅the documentation on defining URL namespaces。

GeoDjango

在Django 1.1中，GeoDjango（即django.contrib.gis）有几个新功能：

  • 支持SpatiaLite - SQLite的空间数据库 - 作为空间后端。
  • 地理聚合（Collect，Extent，MakeLine，Union）和F
  • 新GeoQuerySet方法：collect，geojson和snap_to_grid。
  • GEOSGeometry对象的新列表接口方法。

有关更多详细信息，请参阅GeoDjango文档。

Other improvements

自Django 1.0以来引入的其他新功能和更改包括：

  • CSRF protection middleware已分为两类 - CsrfViewMiddleware检查传入请求，CsrfResponseMiddleware处理传出响应。组合的CsrfMiddleware类（这两者）保留向后兼容性，但是现在推荐使用分裂类，以便允许细粒度控制CSRF处理发生的时间和位置。
  • reverse()和使用它的代码（例如{％ url ％} t3>模板代码）现在可以在Django的管理网站中使用网址，前提是管理网址是通过include(admin.site.urls)（将管理请求发送到admin.site.root视图仍然可以工作，但是管理员中的网址不会是“可逆的”）。
  • Django中的include()函数URLconf模块现在可以接受除模块名称之外的URL模式序列（由patterns()生成）。
  • Django表单的实例（参见the forms overview）现在有两个附加方法，hidden_fields()和visible_fields()分别在表单上隐藏（即＆lt； input type =“hidden”＆gt；）和可见字段。
  • redirect_to通用视图现在接受另一个关键字参数permanent。如果permanent是True，则视图将发出HTTP永久重定向（状态代码301）。如果False，则视图将发出HTTP临时重定向（状态代码302）。
  • 已为DateField和DateTimeField添加了新的数据库查找类型 - week_day。此类型的查找接受1（星期日）和7（星期六）之间的数字，并返回字段值与星期几相匹配的对象。有关详细信息，请参见the full list of lookup types。
  • The {% for %} tag in Django’s template language now accepts an optional {% empty %} clause, to be displayed when {% for %} is asked to loop over an empty sequence. 有关示例，请参见the list of built-in template tags。
  • dumpdata管理命令现在接受单个模型名称作为参数，允许您从特定模型导出数据。
  • 有一个新的safeseq模板过滤器，它像列表中的safe一样工作，将列表中的每个项目标记为安全。
  • Cache backends现在支持incr()和decr()命令增加和减少高速缓存密钥的值。在支持原子增量/减量的高速缓存后端 - 最显着的是，memcached后端 - 这些操作将是原子的，并且相当快。
  • Django now can easily delegate authentication to the Web server via a new authentication backend that supports the standard REMOTE_USER environment variable used for this purpose.
  • 有一个新的django.shortcuts.redirect()函数，可以更轻松地发布给定对象，视图名称或URL的重定向。
  • postgresql_psycopg2后端现在支持native PostgreSQL autocommit。这是一个高级的PostgreSQL特定功能，可以使某些重读应用程序更快一些。

What’s next?

我们会休息一下，然后工作在Django 1.2将开始 - 没有休息的疲惫！如果你想帮助，讨论Django开发，包括朝着1.2版本的进展，每天在django开发者邮件列表：

...以及irc.freenode.net的#django-dev IRC频道中。随意加入讨论！

Django的在线文档还包括如何为Django做出贡献的指针：

对任何级别的贡献 - 开发代码，编写文档或简单地分类故障单，并帮助测试建议的错误修正 - 总是欢迎和赞赏。

这就是它的样子。