          @login_required_m
          def my_view(self, request):
              pass
  
  For those following trunk, this change also applies to other decorators
  introduced since 1.1, including ``csrf_protect``, ``cache_control`` and anything
  created using ``decorator_from_middleware``.
  
  ``ModelForm.is_valid()`` and ``ModelForm.errors``
  -------------------------------------------------
  
  Much of the validation work for ModelForms has been moved down to the model
 
</s> remove ``django.contrib.auth.decorators`` provides the decorators ``login_required``,
``permission_required`` and ``user_passes_test``. Previously it was possible to
use these decorators both on functions (where the first argument is 'request')
and on methods (where the first argument is 'self', and the second argument is
'request'). However, we have found that the trick which enabled this is
flawed. It only works in limited circumstances, and produces errors that are
very difficult to debug when it does not work.

For this reason, the 'auto adapt' behaviour has been removed, and if you are
using these decorators on methods, you will need to manually apply
:func:`django.utils.decorators.method_decorator` to convert the decorator to one
that works with methods. You would change code from this::
 </s> add ``django.contrib.auth.decorators`` provides the decorators
``login_required``, ``permission_required`` and
``user_passes_test``. Previously it was possible to use these
decorators both on functions (where the first argument is 'request')
and on methods (where the first argument is 'self', and the second
argument is 'request'). Unfortunately, flaws were discovered in the
code supporting this: it only works in limited circumstances, and
produces errors that are very difficult to debug when it does not
work.

For this reason, the 'auto adapt' behavior has been removed, and if
you are using these decorators on methods, you will need to manually
apply :func:`django.utils.decorators.method_decorator` to convert the
decorator to one that works with methods. For example, you would
change code from this:: </s> remove result, the ``postgresql`` database backend, which depends on this
library, has been deprecated.
 </s> add result, the ``postgresql`` database backend, which uses this library,
has been deprecated. </s> remove ``LazyObject`` is an undocumented utility class used for lazily wrapping other
objects of unknown type. In Django 1.1 and earlier, it handled introspection in
a non-standard way, depending on wrapped objects implementing a public method
``get_all_members()``. Since this could easily lead to name clashes, it has been
changed to use the standard method, involving ``__members__`` and ``__dir__()``.
If you used ``LazyObject`` in your own code and implemented the
``get_all_members()`` method for wrapped objects, you need to make the following
changes:
 </s> add ``LazyObject`` is an undocumented utility class used for lazily
wrapping other objects of unknown type. In Django 1.1 and earlier, it
handled introspection in a non-standard way, depending on wrapped
objects implementing a public method named
``get_all_members()``. Since this could easily lead to name clashes,
it has been changed to use the standard Python introspection method,
involving ``__members__`` and ``__dir__()``.  If you used
``LazyObject`` in your own code and implemented the
``get_all_members()`` method for wrapped objects, you need to make the
following changes: </s> remove Prior to Django 1.1, Django used a number of settings to control access to a
single database. Django 1.2 introduces support for multiple databases, and as
a result, the way you define database settings has changed.
 </s> add Prior to Django 1.1, Django used a number of settings to control
access to a single database. Django 1.2 introduces support for
multiple databases, and as a result the way you define database
settings has changed. </s> remove Any existing Django settings file will continue to work as expected until
Django 1.4. Until then, old-style database settings will be automatically
translated to the new-style format.
 </s> add Any existing Django settings file will continue to work as expected
until Django 1.4. Until then, old-style database settings will be
automatically translated to the new-style format.
For those of you who've been following the development trunk, this
change also applies to other decorators introduced since 1.1,
including ``csrf_protect``, ``cache_control`` and anything created
using ``decorator_from_middleware``.
          @login_required_m
          def my_view(self, request):
              pass
  
For those of you who've been following the development trunk, this
change also applies to other decorators introduced since 1.1,
including ``csrf_protect``, ``cache_control`` and anything created
using ``decorator_from_middleware``.
For those of you who've been following the development trunk, this
change also applies to other decorators introduced since 1.1,
including ``csrf_protect``, ``cache_control`` and anything created
using ``decorator_from_middleware``.
For those of you who've been following the development trunk, this
change also applies to other decorators introduced since 1.1,
including ``csrf_protect``, ``cache_control`` and anything created
using ``decorator_from_middleware``.
  
  ``ModelForm.is_valid()`` and ``ModelForm.errors``
  -------------------------------------------------
  
  Much of the validation work for ModelForms has been moved down to the model
keep keep keep keep replace replace replace keep keep keep keep keep
 Update 1.2 release notes in anticipation of final release.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13259 bcc190cf-cafb-0310-a4f2-bffc1f526a37 
docs/releases/1.2.txt