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

Fixed #13739 -- Updated release notes to make a note of the changes to Field.db_type. 

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13350 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2010-06-11 01:37:10 +00:00
parent 2597f31ed4
commit ab908685fb
1 changed files with 19 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
docs/releases/1.2.txt
View File

@ -21,11 +21,11 @@ Overview
Django 1.2 introduces several large, important new features, including: Django 1.2 introduces several large, important new features, including:
* Support for `multiple database connections`_ in a single Django instance. * Support for `multiple database connections`_ in a single Django instance.
* `Model validation`_ inspired by Django's form validation. * `Model validation`_ inspired by Django's form validation.
* Vastly `improved protection against Cross-Site Request Forgery`_ (CSRF). * Vastly `improved protection against Cross-Site Request Forgery`_ (CSRF).
* A new `user "messages" framework`_ with support for cookie- and session-based * A new `user "messages" framework`_ with support for cookie- and session-based
message for both anonymous and authenticated users. message for both anonymous and authenticated users.
@ -49,9 +49,9 @@ be found below`_.
.. seealso:: .. seealso::
`Django Advent`_ covered the release of Django 1.2 with a series of `Django Advent`_ covered the release of Django 1.2 with a series of
articles and tutorials that cover some of the new features in depth. articles and tutorials that cover some of the new features in depth.
.. _django advent: http://djangoadvent.com/ .. _django advent: http://djangoadvent.com/
Wherever possible these features have been introduced in a backwards-compatible Wherever possible these features have been introduced in a backwards-compatible
@ -66,7 +66,7 @@ backwards-incompatible. The big changes are:
* The new CSRF protection framework is not backwards-compatible with * The new CSRF protection framework is not backwards-compatible with
the old system. Users of the old system will not be affected until the old system. Users of the old system will not be affected until
the old system is removed in Django 1.4. the old system is removed in Django 1.4.
However, upgrading to the new CSRF protection framework requires a few However, upgrading to the new CSRF protection framework requires a few
important backwards-incompatible changes, detailed in `CSRF Protection`_, important backwards-incompatible changes, detailed in `CSRF Protection`_,
below. below.
@ -74,12 +74,12 @@ backwards-incompatible. The big changes are:
* Authors of custom :class:`~django.db.models.Field` subclasses should be * Authors of custom :class:`~django.db.models.Field` subclasses should be
aware that a number of methods have had a change in prototype, detailed aware that a number of methods have had a change in prototype, detailed
under `get_db_prep_*() methods on Field`_, below. under `get_db_prep_*() methods on Field`_, below.
* The internals of template tags have changed somewhat; authors of custom * The internals of template tags have changed somewhat; authors of custom
template tags that need to store state (e.g. custom control flow tags) template tags that need to store state (e.g. custom control flow tags)
should ensure that their code follows the new rules for `stateful template should ensure that their code follows the new rules for `stateful template
tags`_ tags`_
* The :func:`~django.contrib.auth.decorators.user_passes_test`, * The :func:`~django.contrib.auth.decorators.user_passes_test`,
:func:`~django.contrib.auth.decorators.login_required`, and :func:`~django.contrib.auth.decorators.login_required`, and
:func:`~django.contrib.auth.decorators.permission_required`, decorators :func:`~django.contrib.auth.decorators.permission_required`, decorators
@ -435,6 +435,8 @@ database-compatible values. A custom field might look something like::
class CustomModelField(models.Field): class CustomModelField(models.Field):
# ... # ...
def db_type(self):
# ...
def get_db_prep_save(self, value): def get_db_prep_save(self, value):
# ... # ...
@ -451,6 +453,9 @@ two extra methods have been introduced::
class CustomModelField(models.Field): class CustomModelField(models.Field):
# ... # ...
def db_type(self, connection):
# ...
def get_prep_value(self, value): def get_prep_value(self, value):
# ... # ...
@ -467,10 +472,10 @@ two extra methods have been introduced::
# ... # ...
These changes are required to support multiple databases -- These changes are required to support multiple databases --
``get_db_prep_*`` can no longer make any assumptions regarding the ``db_type`` and ``get_db_prep_*`` can no longer make any assumptions
database for which it is preparing. The ``connection`` argument now regarding the database for which it is preparing. The ``connection``
provides the preparation methods with the specific connection for argument now provides the preparation methods with the specific
which the value is being prepared. connection for which the value is being prepared.
The two new methods exist to differentiate general data-preparation The two new methods exist to differentiate general data-preparation
requirements from requirements that are database-specific. The requirements from requirements that are database-specific. The
@ -603,13 +608,13 @@ new keyword and so is not a valid variable name in this tag.
-------------- --------------
``LazyObject`` is an undocumented-but-often-used utility class used for lazily ``LazyObject`` is an undocumented-but-often-used utility class used for lazily
wrapping other objects of unknown type. wrapping other objects of unknown type.
In Django 1.1 and earlier, it handled introspection in a non-standard way, In Django 1.1 and earlier, it handled introspection in a non-standard way,
depending on wrapped objects implementing a public method named depending on wrapped objects implementing a public method named
``get_all_members()``. Since this could easily lead to name clashes, it has been ``get_all_members()``. Since this could easily lead to name clashes, it has been
changed to use the standard Python introspection method, involving changed to use the standard Python introspection method, involving
``__members__`` and ``__dir__()``. ``__members__`` and ``__dir__()``.
If you used ``LazyObject`` in your own code If you used ``LazyObject`` in your own code
and implemented the ``get_all_members()`` method for wrapped objects, you'll need and implemented the ``get_all_members()`` method for wrapped objects, you'll need