mirror of
https://github.com/django/django.git
synced 2025-07-05 18:29:11 +00:00
[soc2010/test-refactor] Merged changes from trunk up to 13390
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2010/test-refactor@13391 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
222cc77e52
commit
c8624d43cb
@ -1,4 +1,4 @@
|
|||||||
VERSION = (1, 2, 1, 'final', 0)
|
VERSION = (1, 3, 0, 'alpha', 0)
|
||||||
|
|
||||||
def get_version():
|
def get_version():
|
||||||
version = '%s.%s' % (VERSION[0], VERSION[1])
|
version = '%s.%s' % (VERSION[0], VERSION[1])
|
||||||
|
@ -22,7 +22,7 @@ Paragraph 2 with "quotes" and @code@"""
|
|||||||
t = Template("{{ textile_content|textile }}")
|
t = Template("{{ textile_content|textile }}")
|
||||||
rendered = t.render(Context(locals())).strip()
|
rendered = t.render(Context(locals())).strip()
|
||||||
if textile:
|
if textile:
|
||||||
self.assertEqual(rendered, """<p>Paragraph 1</p>
|
self.assertEqual(rendered.replace('\t', ''), """<p>Paragraph 1</p>
|
||||||
|
|
||||||
<p>Paragraph 2 with “quotes” and <code>code</code></p>""")
|
<p>Paragraph 2 with “quotes” and <code>code</code></p>""")
|
||||||
else:
|
else:
|
||||||
|
@ -4,6 +4,8 @@ from optparse import make_option
|
|||||||
|
|
||||||
class Command(BaseCommand):
|
class Command(BaseCommand):
|
||||||
option_list = BaseCommand.option_list + (
|
option_list = BaseCommand.option_list + (
|
||||||
|
make_option('--noinput', action='store_false', dest='interactive', default=True,
|
||||||
|
help='Tells Django to NOT prompt the user for input of any kind.'),
|
||||||
make_option('--addrport', action='store', dest='addrport',
|
make_option('--addrport', action='store', dest='addrport',
|
||||||
type='string', default='',
|
type='string', default='',
|
||||||
help='port number or ipaddr:port to run the server on'),
|
help='port number or ipaddr:port to run the server on'),
|
||||||
@ -18,10 +20,11 @@ class Command(BaseCommand):
|
|||||||
from django.db import connection
|
from django.db import connection
|
||||||
|
|
||||||
verbosity = int(options.get('verbosity', 1))
|
verbosity = int(options.get('verbosity', 1))
|
||||||
|
interactive = options.get('interactive', True)
|
||||||
addrport = options.get('addrport')
|
addrport = options.get('addrport')
|
||||||
|
|
||||||
# Create a test database.
|
# Create a test database.
|
||||||
db_name = connection.creation.create_test_db(verbosity=verbosity)
|
db_name = connection.creation.create_test_db(verbosity=verbosity, autoclobber=not interactive)
|
||||||
|
|
||||||
# Import the fixture data into the test database.
|
# Import the fixture data into the test database.
|
||||||
call_command('loaddata', *fixture_labels, **{'verbosity': verbosity})
|
call_command('loaddata', *fixture_labels, **{'verbosity': verbosity})
|
||||||
|
@ -18,6 +18,22 @@ documentation or reference manuals.
|
|||||||
PostgreSQL notes
|
PostgreSQL notes
|
||||||
================
|
================
|
||||||
|
|
||||||
|
.. versionchanged:: 1.3
|
||||||
|
|
||||||
|
Django supports PostgreSQL 8.0 and higher. If you want to use
|
||||||
|
:ref:`database-level autocommit <postgresql-autocommit-mode>`, a
|
||||||
|
minimum version of PostgreSQL 8.2 is required.
|
||||||
|
|
||||||
|
.. admonition:: Improvements in recent PostgreSQL versions
|
||||||
|
|
||||||
|
PostgreSQL 8.0 and 8.1 `will soon reach end-of-life`_; there have
|
||||||
|
also been a number of significant performance improvements added
|
||||||
|
in recent PostgreSQL versions. Although PostgreSQL 8.0 is the minimum
|
||||||
|
supported version, you would be well advised to use a more recent
|
||||||
|
version if at all possible.
|
||||||
|
|
||||||
|
.. _will soon reach end-of-life: http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy
|
||||||
|
|
||||||
PostgreSQL 8.2 to 8.2.4
|
PostgreSQL 8.2 to 8.2.4
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
@ -39,6 +55,8 @@ database connection is first used and commits the result at the end of the
|
|||||||
request/response handling. The PostgreSQL backends normally operate the same
|
request/response handling. The PostgreSQL backends normally operate the same
|
||||||
as any other Django backend in this respect.
|
as any other Django backend in this respect.
|
||||||
|
|
||||||
|
.. _postgresql-autocommit-mode:
|
||||||
|
|
||||||
Autocommit mode
|
Autocommit mode
|
||||||
~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
@ -84,6 +102,7 @@ protection for multi-call operations.
|
|||||||
|
|
||||||
Indexes for ``varchar`` and ``text`` columns
|
Indexes for ``varchar`` and ``text`` columns
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.1.2
|
.. versionadded:: 1.1.2
|
||||||
|
|
||||||
When specifying ``db_index=True`` on your model fields, Django typically
|
When specifying ``db_index=True`` on your model fields, Django typically
|
||||||
|
@ -804,8 +804,6 @@ with an appropriate extension (e.g. ``json`` or ``xml``). See the
|
|||||||
documentation for ``loaddata`` for details on the specification of fixture
|
documentation for ``loaddata`` for details on the specification of fixture
|
||||||
data files.
|
data files.
|
||||||
|
|
||||||
--noinput
|
|
||||||
~~~~~~~~~
|
|
||||||
The :djadminopt:`--noinput` option may be provided to suppress all user
|
The :djadminopt:`--noinput` option may be provided to suppress all user
|
||||||
prompts.
|
prompts.
|
||||||
|
|
||||||
@ -889,6 +887,11 @@ To run on 1.2.3.4:7000 with a ``test`` fixture::
|
|||||||
|
|
||||||
django-admin.py testserver --addrport 1.2.3.4:7000 test
|
django-admin.py testserver --addrport 1.2.3.4:7000 test
|
||||||
|
|
||||||
|
.. versionadded:: 1.3
|
||||||
|
|
||||||
|
The :djadminopt:`--noinput` option may be provided to suppress all user
|
||||||
|
prompts.
|
||||||
|
|
||||||
validate
|
validate
|
||||||
--------
|
--------
|
||||||
|
|
||||||
|
@ -109,7 +109,7 @@ of to a specific field. You can access these errors with ``NON_FIELD_ERRORS``::
|
|||||||
|
|
||||||
from django.core.validators import ValidationError, NON_FIELD_ERRORS
|
from django.core.validators import ValidationError, NON_FIELD_ERRORS
|
||||||
try:
|
try:
|
||||||
article.full_clean():
|
article.full_clean()
|
||||||
except ValidationError, e:
|
except ValidationError, e:
|
||||||
non_field_errors = e.message_dict[NON_FIELD_ERRORS]
|
non_field_errors = e.message_dict[NON_FIELD_ERRORS]
|
||||||
|
|
||||||
|
@ -286,7 +286,7 @@ a subclass of dictionary. Exceptions are outlined here:
|
|||||||
.. method:: QueryDict.setdefault(key, default)
|
.. method:: QueryDict.setdefault(key, default)
|
||||||
|
|
||||||
Just like the standard dictionary ``setdefault()`` method, except it uses
|
Just like the standard dictionary ``setdefault()`` method, except it uses
|
||||||
``__setitem__`` internally.
|
``__setitem__()`` internally.
|
||||||
|
|
||||||
.. method:: QueryDict.update(other_dict)
|
.. method:: QueryDict.update(other_dict)
|
||||||
|
|
||||||
@ -305,7 +305,7 @@ a subclass of dictionary. Exceptions are outlined here:
|
|||||||
.. method:: QueryDict.items()
|
.. method:: QueryDict.items()
|
||||||
|
|
||||||
Just like the standard dictionary ``items()`` method, except this uses the
|
Just like the standard dictionary ``items()`` method, except this uses the
|
||||||
same last-value logic as ``__getitem()__``. For example::
|
same last-value logic as ``__getitem__()``. For example::
|
||||||
|
|
||||||
>>> q = QueryDict('a=1&a=2&a=3')
|
>>> q = QueryDict('a=1&a=2&a=3')
|
||||||
>>> q.items()
|
>>> q.items()
|
||||||
@ -315,7 +315,7 @@ a subclass of dictionary. Exceptions are outlined here:
|
|||||||
|
|
||||||
Just like the standard dictionary ``iteritems()`` method. Like
|
Just like the standard dictionary ``iteritems()`` method. Like
|
||||||
:meth:`QueryDict.items()` this uses the same last-value logic as
|
:meth:`QueryDict.items()` this uses the same last-value logic as
|
||||||
:meth:`QueryDict.__getitem()__`.
|
:meth:`QueryDict.__getitem__()`.
|
||||||
|
|
||||||
.. method:: QueryDict.iterlists()
|
.. method:: QueryDict.iterlists()
|
||||||
|
|
||||||
@ -325,7 +325,7 @@ a subclass of dictionary. Exceptions are outlined here:
|
|||||||
.. method:: QueryDict.values()
|
.. method:: QueryDict.values()
|
||||||
|
|
||||||
Just like the standard dictionary ``values()`` method, except this uses the
|
Just like the standard dictionary ``values()`` method, except this uses the
|
||||||
same last-value logic as ``__getitem()__``. For example::
|
same last-value logic as ``__getitem__()``. For example::
|
||||||
|
|
||||||
>>> q = QueryDict('a=1&a=2&a=3')
|
>>> q = QueryDict('a=1&a=2&a=3')
|
||||||
>>> q.values()
|
>>> q.values()
|
||||||
|
@ -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
|
||||||
|
31
docs/releases/1.3.txt
Normal file
31
docs/releases/1.3.txt
Normal file
@ -0,0 +1,31 @@
|
|||||||
|
.. _releases-1.3:
|
||||||
|
|
||||||
|
============================================
|
||||||
|
Django 1.3 release notes - UNDER DEVELOPMENT
|
||||||
|
============================================
|
||||||
|
|
||||||
|
This page documents release notes for the as-yet-unreleased Django
|
||||||
|
1.3. As such, it's tentative and subject to change. It provides
|
||||||
|
up-to-date information for those who are following trunk.
|
||||||
|
|
||||||
|
Django 1.3 includes a number of nifty `new features`_, lots of bug
|
||||||
|
fixes and an easy upgrade path from Django 1.2.
|
||||||
|
|
||||||
|
.. _new features: `What's new in Django 1.3`_
|
||||||
|
|
||||||
|
.. _backwards-incompatible-changes-1.3:
|
||||||
|
|
||||||
|
Backwards-incompatible changes in 1.3
|
||||||
|
=====================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Features deprecated in 1.3
|
||||||
|
==========================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
What's new in Django 1.3
|
||||||
|
========================
|
||||||
|
|
||||||
|
|
@ -16,6 +16,13 @@ up to and including the new version.
|
|||||||
Final releases
|
Final releases
|
||||||
==============
|
==============
|
||||||
|
|
||||||
|
1.3 release
|
||||||
|
-----------
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
1.3
|
||||||
|
|
||||||
1.2 release
|
1.2 release
|
||||||
-----------
|
-----------
|
||||||
.. toctree::
|
.. toctree::
|
||||||
|
Loading…
x
Reference in New Issue
Block a user