mirror of
https://github.com/django/django.git
synced 2024-12-25 02:26:12 +00:00
1858e47672
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17937 bcc190cf-cafb-0310-a4f2-bffc1f526a37
164 lines
6.8 KiB
Plaintext
164 lines
6.8 KiB
Plaintext
================================
|
|
Django 1.1 alpha 1 release notes
|
|
================================
|
|
|
|
February 23, 2009
|
|
|
|
Welcome to Django 1.1 alpha 1!
|
|
|
|
This is the first in a series of preview/development releases leading up to the
|
|
eventual release of Django 1.1, currently scheduled to take place in April 2009.
|
|
This release is primarily targeted at developers who are interested in trying
|
|
out new features and testing the Django codebase to help identify and resolve
|
|
bugs prior to the final 1.1 release.
|
|
|
|
As such, this release is *not* intended for production use, and any such use is
|
|
discouraged.
|
|
|
|
What's new in Django 1.1 alpha 1
|
|
================================
|
|
|
|
ORM improvements
|
|
----------------
|
|
|
|
Two major enhancements have been added to Django's object-relational mapper
|
|
(ORM):
|
|
|
|
Aggregate support
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
.. currentmodule:: django.db.models
|
|
|
|
It's now possible to run SQL aggregate queries (i.e. ``COUNT()``, ``MAX()``,
|
|
``MIN()``, etc.) from within Django's ORM. You can choose to either return the
|
|
results of the aggregate directly, or else annotate the objects in a
|
|
:class:`QuerySet` with the results of the aggregate query.
|
|
|
|
This feature is available as new :meth:`QuerySet.aggregate()`` and
|
|
:meth:`QuerySet.annotate()`` methods, and is covered in detail in :doc:`the ORM
|
|
aggregation documentation </topics/db/aggregation>`
|
|
|
|
Query expressions
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
Queries can now refer to a another field on the query and can traverse
|
|
relationships to refer to fields on related models. This is implemented in the
|
|
new :class:`F` object; for full details, including examples, consult the
|
|
:ref:`documentation for F expressions <query-expressions>`.
|
|
|
|
Performance improvements
|
|
------------------------
|
|
|
|
.. currentmodule:: django.test
|
|
|
|
Tests written using Django's :doc:`testing framework </topics/testing>` now run
|
|
dramatically faster (as much as 10 times faster in many cases).
|
|
|
|
This was accomplished through the introduction of transaction-based tests: when
|
|
using :class:`django.test.TestCase`, your tests will now be run in a transaction
|
|
which is rolled back when finished, instead of by flushing and re-populating the
|
|
database. This results in an immense speedup for most types of unit tests. See
|
|
the documentation for :class:`TestCase` and :class:`TransactionTestCase` for a
|
|
full description, and some important notes on database support.
|
|
|
|
Other improvements
|
|
------------------
|
|
|
|
Other new features and changes introduced since Django 1.0 include:
|
|
|
|
* The :doc:`CSRF protection middleware </ref/contrib/csrf>` has been split into
|
|
two classes -- ``CsrfViewMiddleware`` checks incoming requests, and
|
|
``CsrfResponseMiddleware`` processes outgoing responses. The combined
|
|
``CsrfMiddleware`` class (which does both) remains for
|
|
backwards-compatibility, but using the split classes is now recommended in
|
|
order to allow fine-grained control of when and where the CSRF processing
|
|
takes place.
|
|
|
|
* :func:`~django.core.urlresolvers.reverse` and code which uses it (e.g., the
|
|
``{% url %}`` template tag) now works with URLs in Django's administrative
|
|
site, provided that the admin URLs are set up via ``include(admin.site.urls)``
|
|
(sending admin requests to the ``admin.site.root`` view still works, but URLs
|
|
in the admin will not be "reversible" when configured this way).
|
|
|
|
* The ``include()`` function in Django URLconf modules can now accept sequences
|
|
of URL patterns (generated by ``patterns()``) in addition to module names.
|
|
|
|
* Instances of Django forms (see :doc:`the forms overview </topics/forms/index>`)
|
|
now have two additional methods, ``hidden_fields()`` and ``visible_fields()``,
|
|
which return the list of hidden -- i.e., ``<input type="hidden">`` -- and
|
|
visible fields on the form, respectively.
|
|
|
|
* The ``redirect_to`` generic view
|
|
now accepts an additional keyword argument
|
|
``permanent``. If ``permanent`` is ``True``, the view will emit an HTTP
|
|
permanent redirect (status code 301). If ``False``, the view will emit an HTTP
|
|
temporary redirect (status code 302).
|
|
|
|
* A new database lookup type -- ``week_day`` -- has been added for ``DateField``
|
|
and ``DateTimeField``. This type of lookup accepts a number between 1 (Sunday)
|
|
and 7 (Saturday), and returns objects where the field value matches that day
|
|
of the week. See :ref:`the full list of lookup types <field-lookups>` for
|
|
details.
|
|
|
|
* 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. See :doc:`the list of built-in template tags
|
|
</ref/templates/builtins>` for examples of this.
|
|
|
|
The Django 1.1 roadmap
|
|
======================
|
|
|
|
Before Django 1.1 goes final, several other preview/development releases will be
|
|
made available. The current schedule consists of at least the following:
|
|
|
|
* Week of *March 20, 2009:* Django 1.1 beta 1, at which point Django 1.1 will
|
|
be in "feature freeze": no new features will be implemented for 1.1
|
|
past that point, and all new feature work will be deferred to
|
|
Django 1.2.
|
|
|
|
* Week of *April 2, 2009:* Django 1.1 release candidate. At this point all
|
|
strings marked for translation must freeze to allow translations to
|
|
be submitted in advance of the final release.
|
|
|
|
* Week of *April 13, 2009:* Django 1.1 final.
|
|
|
|
If deemed necessary, additional alpha, beta or release candidate packages will
|
|
be issued prior to the final 1.1 release.
|
|
|
|
What you can do to help
|
|
=======================
|
|
|
|
In order to provide a high-quality 1.1 release, we need your help. Although this
|
|
alpha release is, again, *not* intended for production use, you can help the
|
|
Django team by trying out the alpha codebase in a safe test environment and
|
|
reporting any bugs or issues you encounter. The Django ticket tracker is the
|
|
central place to search for open issues:
|
|
|
|
* https://code.djangoproject.com/timeline
|
|
|
|
Please open new tickets if no existing ticket corresponds to a problem you're
|
|
running into.
|
|
|
|
Additionally, discussion of Django development, including progress toward the
|
|
1.1 release, takes place daily on the django-developers mailing list:
|
|
|
|
* http://groups.google.com/group/django-developers
|
|
|
|
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
|
|
interested in helping out with Django's development, feel free to join the
|
|
discussions there.
|
|
|
|
Django's online documentation also includes pointers on how to contribute to
|
|
Django:
|
|
|
|
* :doc:`How to contribute to Django </internals/contributing/index>`
|
|
|
|
Contributions on any level -- developing code, writing documentation or simply
|
|
triaging tickets and helping to test proposed bugfixes -- are always welcome and
|
|
appreciated.
|
|
|
|
Development sprints for Django 1.1 will also be taking place at PyCon US 2009,
|
|
on the dedicated sprint days (March 30 through April 2), and anyone who wants to
|
|
help out is welcome to join in, either in person at PyCon or virtually in the
|
|
IRC channel or on the mailing list.
|