欢迎来到 Django 1.0 版本！
我们期待这一刻已经三年多了，现在它终于来了。Django 1.0是Django开发过程中最大的一个里程碑:这是一个让一群完美主义者感到自豪的Web框架。
Django 1.0 作为一个开发了三年多的开源项目，得到了数百名开发人员的支持，并被翻译成50多种语言，现在仍广泛的被世界各地的开发人员用于各种工作中
An interesting historical note: when Django was first released in July 2005, the initial released version of Django came from an internal repository at revision number 8825. Django 1.0 represents revision 8961 of our public repository. It seems fitting that our 1.0 release comes at the moment where community contributions overtake those made privately.
The release of Django 1.0 comes with a promise of API stability and forwards-compatibility. In a nutshell, this means that code you develop against Django 1.0 will continue to work against 1.1 unchanged, and you should need to make only minor changes for any 1.X release.
查阅文档：“API稳定性指南”了解详细信息
Django 1.0 有许多与 Django 0.96 不兼容的修改。如果您有Django 0.96 的应用需要移植，请查看我们的详细移植指南。
查看不兼容的更改列表请移步：https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.
很多
从 Django 0.96 开始，我们已经提交了 4000 多次的代码，修复了 2000 多个漏洞，并编辑了大约 350000 行的代码。我们还添加了 40000 行的新文档，极大的改进了现有的内容。
In fact, new documentation is one of our favorite features of Django 1.0, so we might as well start there. First, there's a new documentation site:
The documentation has been greatly improved, cleaned up, and generally made awesome. There's now dedicated search, indexes, and more.
We can't possibly document everything that's new in 1.0, but the documentation will be your definitive guide. Anywhere you see something like:
此功能是 Django 1.0 中的新功能
You'll know that you're looking at something new or changed.
The other major highlights of Django 1.0 are:
The Django administrative interface (django.contrib.admin) has been
completely refactored; admin definitions are now completely decoupled from model
definitions (no more class Admin declaration in models!), rewritten to use
Django's new form-handling library (introduced in the 0.96 release as
django.newforms, and now available as simply django.forms) and
redesigned with extensibility and customization in mind. Full documentation for
the admin application is available online in the official Django documentation:
See the admin reference for details
Django's internals have been refactored to use Unicode throughout; this drastically simplifies the task of dealing with non-Western-European content and data in Django. Additionally, utility functions have been provided to ease interoperability with third-party libraries and systems which may or may not handle Unicode gracefully. Details are available in Django's Unicode-handling documentation.
参见 Unicode 数据。
Django's object-relational mapper -- the component which provides the mapping between Django model classes and your database, and which mediates your database queries -- has been dramatically improved by a massive refactoring. For most users of Django this is backwards-compatible; the public-facing API for database querying underwent a few minor changes, but most of the updates took place in the ORM's internals. A guide to the changes, including backwards-incompatible modifications and mentions of new features opened up by this refactoring, is available on the Django wiki.
To provide improved security against cross-site scripting (XSS) vulnerabilities,
Django's template system now automatically escapes the output of variables. This
behavior is configurable, and allows both variables and larger template
constructs to be marked as safe (requiring no escaping) or unsafe (requiring
escaping). A full guide to this feature is in the documentation for the
autoescape tag.
django.contrib.gis (GeoDjango)¶A project over a year in the making, this adds world-class GIS (Geographic
Information Systems) support to Django, in the form of a contrib
application. Its documentation is currently being maintained externally, and
will be merged into the main Django documentation shortly. Huge thanks go to
Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts in
creating and completing this feature.
See GeoDjango for details.
Django's built-in FileField and ImageField now can take advantage of
pluggable file-storage backends, allowing extensive customization of where and
how uploaded files get stored by Django. For details, see the files
documentation; big thanks go to Marty Alchin for putting in the
hard work to get this completed.
Thanks to a lot of work from Leo Soto during a Google Summer of Code project, Django's codebase has been refactored to remove incompatibilities with Jython, an implementation of Python written in Java, which runs Python code on the Java Virtual Machine. Django is now compatible with the forthcoming Jython 2.5 release.
Classes are now included in django.contrib.contenttypes which can be used to
support generic relations in both the admin interface and in end-user forms. See
the documentation for generic relations for details.
INSERT/UPDATE distinction¶Although Django's default behavior of having a model's save() method
automatically determine whether to perform an INSERT or an UPDATE at the
SQL level is suitable for the majority of cases, there are occasional situations
where forcing one or the other is useful. As a result, models can now support an
additional parameter to save() which can force a specific operation.
See 强制执行 INSERT 或 UPDATE for details.
CacheMiddleware¶Django's CacheMiddleware has been split into three classes:
CacheMiddleware itself still exists and retains all of its previous
functionality, but it is now built from two separate middleware classes which
handle the two parts of caching (inserting into and reading from the cache)
separately, offering additional flexibility for situations where combining these
functions into a single middleware posed problems.
Full details, including updated notes on appropriate use, are in the caching documentation.
django.contrib.comments¶As part of a Google Summer of Code project, Thejaswi Puthraya carried out a major rewrite and refactoring of Django's bundled comment system, greatly increasing its flexibility and customizability.
A number of features and methods which had previously been marked as deprecated,
and which were scheduled for removal prior to the 1.0 release, are no longer
present in Django. These include imports of the form library from
django.newforms (now located simply at django.forms), the
form_for_model and form_for_instance helper functions (which have been
replaced by ModelForm) and a number of deprecated features which were
replaced by the dispatcher, file-uploading and file-storage refactorings
introduced in the Django 1.0 alpha releases.
We've done our best to make Django 1.0 as solid as possible, but unfortunately there are a couple of issues that we know about in the release.
to_field¶If you're using multiple table model inheritance, be aware of this caveat: child models using a custom
parent_link and to_field will cause database integrity errors. A set of
models like the following are not valid:
class Parent(models.Model):
name = models.CharField(max_length=10)
other_value = models.IntegerField(unique=True)
class Child(Parent):
father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True)
value = models.IntegerField()
这个漏洞将在 Django 的下一个版本中修复。
Django attempts to support as many features as possible on all database backends. However, not all database backends are alike, and in particular many of the supported database differ greatly from version to version. It's a good idea to checkout our notes on supported database:
5月 26, 2021