Django 1.4发布说明--Django 1.4 的新特性

最新推荐文章于 2024-06-18 06:43:11 发布

贱圣

最新推荐文章于 2024-06-18 06:43:11 发布

阅读量638

点赞数

分类专栏： python django

python 同时被 2 个专栏收录

11 篇文章 0 订阅

订阅专栏

django

2 篇文章 0 订阅

订阅专栏

欢迎使用Django 1.4!

这个发布说明包含了一些新的特性，已经当你从Django 1.3 或更老版本升级到 1.4 时需要知道的一些向后不兼容的变化。我们也扔掉了一些特性，在我们的 our deprecation plan 里面详细列出来了，我们已经开始否决一些特性。

综述

Django 1.4 里面最大的变化是在处理时间的时候添加了对于时区的支持。当可用的时候，Django 将会把时间作为UTC时间进行存储，使用内部时区感知对象，并且在显示的时候把时间转化用户本地的时区时间。

如果你把现有的项目升级到 Django 1.4 ,并且转换到时区感知模式的时候你需要注意：这个新的模式不允许一些相当草率的行为。我们鼓励大家在升级的时候查看 timezone migration guide 和 timezone 。

其他的 Django 1.4 里面值得注意的新特性：

一些ORM方面的改进，包括对于 select for update 的支持，大大改善大量插入数据时的表现。还有 QuerySet.prefetch_related ，一个在select_related() 不管用的时候用来批量加载相关的对象。
一些很好的安全增项，包括改善秘密的散列（支持PBKDF2 和bcrypt），新的用于暗码标记的工具，几个CSRF的改进和简单的点击劫持保护。
更新了默认的项目文件结构和 manage.py、移除了先前版本里面的‘魔法’。对于不喜欢新的文件结构的人，你可以使用自定义的项目和模板来代替。
支持了内置浏览器测试框架（例如Selenium）。
还有很多，往下看吧：）

任何可能的情况下，我们都会试着介绍我们的API 稳定方针里面的一些新特性的向后兼容性。可是，就像之前的一些发布一样，Django 1.4 带来了一些向后兼容的改变，从以前版本升级的人需要把以下的清单，仔细阅读一下。

Python 兼容性

Django 1.4 放弃了对于Python 2.4 的支持。Python 2.5 现在是Django 支持的最低版本。Django 1.4 在Python 2.5 2.5 2.7上全部测试通过。

这个变化只会影响一小部分的Django 用户，现在大部分的系统已经迁移到了Python 2.5 或更新的版本了。如果你还在用 Python 2.4 ，你现在只能用 Django 1.3 直到你升级。对于 Django 1.3 的安全支持会一直持续到 Django 1.5 发布的时候。

Django 现在暂时不支持 Python 3.0 及以上版本，在发布 Django 之前的一些时候，我们计划发布一个文档来描述如何从 Python 2.x 升级到 Python 3.x。

Django 有什么新的东西？

对于时区的支持

在先前的版本里，Django 使用本地的时间（没有把时间与时区联系起来），把它让给每个开发者来决定时间。这会引发一些很微妙的时区相关的bug 。

在Django 1.4 里面，你可以转而使用 Django 里面一个更加准确的时区感知模式。在这个模式里，Django 把时间和数据转化为UTC 时间存储与数据库，有一个内部时区感知模块，然后在模板中将时间转化为用户所在的时区。使用这个特性的原因如下：

为全球的用户来转化你的时间数据。
在数据库里存储 UTC 时间有很好的可移植性和互用性。
避免在下夏令时转化的时候破坏数据。

时区支持是在创建项目的时候默认支持的。如果你想在一个现有的项目里使用这个新特性，阅读一下migration guide ，如果碰到一些偶然的问题，这里有一个很有用的 FAQ 。

支持浏览器内建的测试框架

Django 1.4 现在支持并集成了浏览器内建的测试框架，比如 Selenium 。新的 django.test.LiveServerTestCase 这个基类让你能够更全面地测试网站前端到后端的交互。可以通过看 documentation来获取更多细节和例子。

升级默认的项目结构和 manage.py

在 Django 1.4 里面新建项目的时候，默认的项目结构和 manage.py 都已经变化了，它修复了之前的 manage.py 在处理 Python 导入路径的时候会引发 2次导入，和一些很难以发现的路径问题。

先前版本的 manage.py 的功能被弃用，在将项目升级到 Django 1.4 的时候需要更新它们的 manage.py 文件。

新的 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 }} 里面应该用项目名来代替

如果项目里的settings, URLconfs , apps 被导入并使用项目名作为前缀，那么新的manage.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 导入，把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 和 startprject 的时候都来制定目标目录作为第二个参数：

django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project

想获取更多的信息，可以查看 startapp 和 startproject 的文档。
改善了WSGI的支持
startproject 管理命令现在会添加一个 wsgi.py 的模块来初始化项目结构，包括一个简单的 wsgi 应用来帮助进行部署。

现在 built-in development server 支持使用一个外部定义的WSGI ，这使得你使用部署时的 WSGI 配置来运行 runserver 成为了可能

新的 WSGI_APPLICATION 设置允许你配置运行的时候启动哪一个 runserver 。

SELECT FOR UPDATE 的支持

Django 1.4 包含了QuerySet.select_for_update()这个方法，它会生成 SELECT ... FOR UPDATE 这样的查询语句。它会锁住这些行知道事务结束，这意味着其他的事务无法改变或删除这些行。

看更多的细节，可以看相关文档 select_for_update()。

ORM 里面添加了 Model.objects.bulk_create

这个方法让你更有效地创建多个对象。它在你有很多的对象的时候显著改善性能。

这是 Django 的内部功能，意味着有一些操作会有性能提升。

更多的细节，可以看相关文档 bulk_create() 。

QuerySet.prefetch_related

跟 select_related()有点类似但是范围和策略不同， prefetch_related() 这个方法已经被加入了QuerySet 中。这个方法会返回一个新的 QuerySet 对象，会在查询进行评估的时候对相关的一批内容进行预取出。它可以修复你的代码进行查询的时候的性能问题。

改善密码散列

Django 的验证系统（django.contrib.auth）使用单向算法来存储密码。Django 1.3 使用 SHA1 算法，但是处理速度的增长和理论显示，SHA1 并不是像我们希望的那么安全。因此，Django 1.4 里面引入了一个新的密码存储系统：默认情况下，Django 使用 PBKDF2 算法。你也可以很容易的选择不同的算法。更多的细节，见文档 How Django stores passwords 。

HTML5 DOCTYPE

我们已经把 admin 和其他捆绑的模板转向使用 html5 doctype 。同时，Django 也会很小心地维持与老浏览器的兼容，这个变化意味着你可以在 admin 里面使用任何 HTML5 的新特性不会失去 HTML 的正确性或重写之前的模板

admin 界面里面的 list_filter

在 Django 1.4 之前，admin 里面你可以通过制定一个字段查找来指定 change list filter ，但是它不允许你自定义过滤条件，它已经被调整成一个简单的 API 。更多的细节，见文档 list_filter 。

admin 界面里的多重分类

admin 的 change list 里面支持通过多列来进行分类，它会遵循 ordering里的所有元素，并且模拟桌面界面上面的样子进行分类。我们添加了get_ordering()方法来动态地指定排序规则。

贱圣

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Django 1.4发布说明--Django 1.4 的新特性

欢迎使用Django 1.4! 这个发布说明包含了一些新的特性，已经当你从Django 1.3 或更老版本升级到 1.4 时需要知道的一些向后不兼容的变化。我们也扔掉了一些特性，在我们的 our deprecation plan 里面详细列出来了，我们已经开始否决一些特性。综述Django 1.4 里面最大的变化是在处理时间的时候添加了对于时区的支持。当可用的时候，Dj
复制链接

扫一扫