p15693087
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Cleaned up some reST errors in the 1.1 alpha release notes, and made a few minor edits. 

git-svn-id: http://code.djangoproject.com/svn/django/trunk@9895 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jacob Kaplan-Moss 2009-02-24 02:21:09 +00:00
parent 4251c6020c
commit 17bb750b08
2 changed files with 113 additions and 110 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

222
docs/releases/1.1-alpha-1.txt
View File

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

1
docs/releases/index.txt
View File

@ -19,6 +19,7 @@ changes made in that version.
1.0 1.0
1.0.1 1.0.1
1.0.2 1.0.2
1.1-alpha-1
.. seealso:: .. seealso::