mirror of https://github.com/django/django.git
Edited stuff from [17543] to [17629]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17630 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
3ed0b6ed64
commit
2ade1e916f
|
@ -13,7 +13,7 @@ from .models import City, PennsylvaniaCity, State
|
||||||
class GeoRegressionTests(TestCase):
|
class GeoRegressionTests(TestCase):
|
||||||
|
|
||||||
def test01_update(self):
|
def test01_update(self):
|
||||||
"Testing GeoQuerySet.update(), see #10411."
|
"Testing GeoQuerySet.update(). See #10411."
|
||||||
pnt = City.objects.get(name='Pueblo').point
|
pnt = City.objects.get(name='Pueblo').point
|
||||||
bak = pnt.clone()
|
bak = pnt.clone()
|
||||||
pnt.y += 0.005
|
pnt.y += 0.005
|
||||||
|
@ -25,7 +25,7 @@ class GeoRegressionTests(TestCase):
|
||||||
self.assertEqual(bak, City.objects.get(name='Pueblo').point)
|
self.assertEqual(bak, City.objects.get(name='Pueblo').point)
|
||||||
|
|
||||||
def test02_kmz(self):
|
def test02_kmz(self):
|
||||||
"Testing `render_to_kmz` with non-ASCII data, see #11624."
|
"Testing `render_to_kmz` with non-ASCII data. See #11624."
|
||||||
name = '\xc3\x85land Islands'.decode('iso-8859-1')
|
name = '\xc3\x85land Islands'.decode('iso-8859-1')
|
||||||
places = [{'name' : name,
|
places = [{'name' : name,
|
||||||
'description' : name,
|
'description' : name,
|
||||||
|
@ -36,7 +36,7 @@ class GeoRegressionTests(TestCase):
|
||||||
@no_spatialite
|
@no_spatialite
|
||||||
@no_mysql
|
@no_mysql
|
||||||
def test03_extent(self):
|
def test03_extent(self):
|
||||||
"Testing `extent` on a table with a single point, see #11827."
|
"Testing `extent` on a table with a single point. See #11827."
|
||||||
pnt = City.objects.get(name='Pueblo').point
|
pnt = City.objects.get(name='Pueblo').point
|
||||||
ref_ext = (pnt.x, pnt.y, pnt.x, pnt.y)
|
ref_ext = (pnt.x, pnt.y, pnt.x, pnt.y)
|
||||||
extent = City.objects.filter(name='Pueblo').extent()
|
extent = City.objects.filter(name='Pueblo').extent()
|
||||||
|
@ -44,14 +44,14 @@ class GeoRegressionTests(TestCase):
|
||||||
self.assertAlmostEqual(ref_val, val, 4)
|
self.assertAlmostEqual(ref_val, val, 4)
|
||||||
|
|
||||||
def test04_unicode_date(self):
|
def test04_unicode_date(self):
|
||||||
"Testing dates are converted properly, even on SpatiaLite, see #16408."
|
"Testing dates are converted properly, even on SpatiaLite. See #16408."
|
||||||
founded = datetime(1857, 5, 23)
|
founded = datetime(1857, 5, 23)
|
||||||
mansfield = PennsylvaniaCity.objects.create(name='Mansfield', county='Tioga', point='POINT(-77.071445 41.823881)',
|
mansfield = PennsylvaniaCity.objects.create(name='Mansfield', county='Tioga', point='POINT(-77.071445 41.823881)',
|
||||||
founded=founded)
|
founded=founded)
|
||||||
self.assertEqual(founded, PennsylvaniaCity.objects.dates('founded', 'day')[0])
|
self.assertEqual(founded, PennsylvaniaCity.objects.dates('founded', 'day')[0])
|
||||||
|
|
||||||
def test05_empty_count(self):
|
def test05_empty_count(self):
|
||||||
"Testing that PostGISAdapter.__eq__ does check empty strings, see #13670"
|
"Testing that PostGISAdapter.__eq__ does check empty strings. See #13670."
|
||||||
# contrived example, but need a geo lookup paired with an id__in lookup
|
# contrived example, but need a geo lookup paired with an id__in lookup
|
||||||
pueblo = City.objects.get(name='Pueblo')
|
pueblo = City.objects.get(name='Pueblo')
|
||||||
state = State.objects.filter(poly__contains=pueblo.point)
|
state = State.objects.filter(poly__contains=pueblo.point)
|
||||||
|
@ -61,6 +61,6 @@ class GeoRegressionTests(TestCase):
|
||||||
self.assertEqual(cities_within_state.count(), 1)
|
self.assertEqual(cities_within_state.count(), 1)
|
||||||
|
|
||||||
def test06_defer_or_only_with_annotate(self):
|
def test06_defer_or_only_with_annotate(self):
|
||||||
"Regression for #16409 - make sure defer() and only() work with annotate()"
|
"Regression for #16409. Make sure defer() and only() work with annotate()"
|
||||||
self.assertIsInstance(list(City.objects.annotate(Count('point')).defer('name')), list)
|
self.assertIsInstance(list(City.objects.annotate(Count('point')).defer('name')), list)
|
||||||
self.assertIsInstance(list(City.objects.annotate(Count('point')).only('name')), list)
|
self.assertIsInstance(list(City.objects.annotate(Count('point')).only('name')), list)
|
||||||
|
|
|
@ -40,15 +40,15 @@ class Options(object):
|
||||||
self.abstract = False
|
self.abstract = False
|
||||||
self.managed = True
|
self.managed = True
|
||||||
self.proxy = False
|
self.proxy = False
|
||||||
# For any class which is a proxy (including automatically created
|
# For any class that is a proxy (including automatically created
|
||||||
# classes for deferred object loading) the proxy_for_model tells
|
# classes for deferred object loading), proxy_for_model tells us
|
||||||
# which class this model is proxying. Note that proxy_for_model
|
# which class this model is proxying. Note that proxy_for_model
|
||||||
# can create a chain of proxy models. For non-proxy models the
|
# can create a chain of proxy models. For non-proxy models, the
|
||||||
# variable is always None.
|
# variable is always None.
|
||||||
self.proxy_for_model = None
|
self.proxy_for_model = None
|
||||||
# For any non-abstract class the concrete class is the model
|
# For any non-abstract class, the concrete class is the model
|
||||||
# in the end of the proxy_for_model chain. In particular, for
|
# in the end of the proxy_for_model chain. In particular, for
|
||||||
# concrete models the concrete_model is always the class itself.
|
# concrete models, the concrete_model is always the class itself.
|
||||||
self.concrete_model = None
|
self.concrete_model = None
|
||||||
self.parents = SortedDict()
|
self.parents = SortedDict()
|
||||||
self.duplicate_targets = {}
|
self.duplicate_targets = {}
|
||||||
|
|
|
@ -12,14 +12,14 @@ container server coded in pure C.
|
||||||
Prerequisite: uWSGI
|
Prerequisite: uWSGI
|
||||||
===================
|
===================
|
||||||
|
|
||||||
The wiki describes several `installation procedures`_. Using pip, the python
|
The uWSGI wiki describes several `installation procedures`_. Using pip, the
|
||||||
package manager, installing any uWSGI version can be done with one command
|
Python package manager, you can install any uWSGI version with a single
|
||||||
line. For example::
|
command. For example::
|
||||||
|
|
||||||
# install current stable version
|
# Install current stable version.
|
||||||
pip install uwsgi
|
pip install uwsgi
|
||||||
|
|
||||||
# or install LTS (long term support)
|
# Or install LTS (long term support).
|
||||||
pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz
|
pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz
|
||||||
|
|
||||||
.. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
|
.. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
|
||||||
|
@ -27,7 +27,7 @@ line. For example::
|
||||||
uWSGI model
|
uWSGI model
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
uWSGI operates on a client-server model. Your Web server (ie. nginx, Apache)
|
uWSGI operates on a client-server model. Your Web server (e.g., nginx, Apache)
|
||||||
communicates with a django-uwsgi "worker" process to serve dynamic content.
|
communicates with a django-uwsgi "worker" process to serve dynamic content.
|
||||||
See uWSGI's `background documentation`_ for more detail.
|
See uWSGI's `background documentation`_ for more detail.
|
||||||
|
|
||||||
|
@ -36,13 +36,13 @@ See uWSGI's `background documentation`_ for more detail.
|
||||||
Configuring and starting the uWSGI server for Django
|
Configuring and starting the uWSGI server for Django
|
||||||
----------------------------------------------------
|
----------------------------------------------------
|
||||||
|
|
||||||
uWSGI supports multiple ways to configure the process, see uWSGI's
|
uWSGI supports multiple ways to configure the process. See uWSGI's
|
||||||
`configuration documentation`_ and `examples`_
|
`configuration documentation`_ and `examples`_
|
||||||
|
|
||||||
.. _configuration documentation: http://projects.unbit.it/uwsgi/wiki/Doc
|
.. _configuration documentation: http://projects.unbit.it/uwsgi/wiki/Doc
|
||||||
.. _examples: http://projects.unbit.it/uwsgi/wiki/Example
|
.. _examples: http://projects.unbit.it/uwsgi/wiki/Example
|
||||||
|
|
||||||
An example command to start a uWSGI server::
|
Here's an example command to start a uWSGI server::
|
||||||
|
|
||||||
uwsgi --chdir=/path/to/your/project
|
uwsgi --chdir=/path/to/your/project
|
||||||
--module='mysite.wsgi:application' \
|
--module='mysite.wsgi:application' \
|
||||||
|
@ -52,27 +52,28 @@ An example command to start a uWSGI server::
|
||||||
--processes=5 \ # number of worker processes
|
--processes=5 \ # number of worker processes
|
||||||
--uid=1000 --gid=2000 \ # if root, uwsgi can drop privileges
|
--uid=1000 --gid=2000 \ # if root, uwsgi can drop privileges
|
||||||
--harakiri=20 \ # respawn processes taking more than 20 seconds
|
--harakiri=20 \ # respawn processes taking more than 20 seconds
|
||||||
--limit-as=128 \ # limit the project to 128 Megabytes
|
--limit-as=128 \ # limit the project to 128 MB
|
||||||
--max-requests=5000 \ # respawn processes after serving 5000 requests
|
--max-requests=5000 \ # respawn processes after serving 5000 requests
|
||||||
--vacuum \ # clear environment on exit
|
--vacuum \ # clear environment on exit
|
||||||
--home=/path/to/virtual/env \ # optionnal path to a virtualenv
|
--home=/path/to/virtual/env \ # optional path to a virtualenv
|
||||||
--daemonize=/var/log/uwsgi/yourproject.log # background the process
|
--daemonize=/var/log/uwsgi/yourproject.log # background the process
|
||||||
|
|
||||||
This assumes that you have a top-level project package named ``mysite``, and
|
This assumes you have a top-level project package named ``mysite``, and
|
||||||
within it a module :file:`mysite/wsgi.py` that contains a WSGI ``application``
|
within it a module :file:`mysite/wsgi.py` that contains a WSGI ``application``
|
||||||
object. This is the layout you will have if you ran ``django-admin.py
|
object. This is the layout you'll have if you ran ``django-admin.py
|
||||||
startproject mysite`` (using your own project name in place of ``mysite``) with
|
startproject mysite`` (using your own project name in place of ``mysite``) with
|
||||||
a recent version of Django. If this file does not exist, you'll need to create
|
a recent version of Django. If this file doesn't exist, you'll need to create
|
||||||
it. See the :doc:`/howto/deployment/wsgi/index` documentation for the default
|
it. See the :doc:`/howto/deployment/wsgi/index` documentation for the default
|
||||||
contents you should put in this file, and what else you can add to it.
|
contents you should put in this file and what else you can add to it.
|
||||||
|
|
||||||
The Django-specific options here are:
|
The Django-specific options here are:
|
||||||
|
|
||||||
* ``chdir``: the path to the directory that needs to be on Python's import path; i.e. the directory containing the ``mysite`` package.
|
* ``chdir``: The path to the directory that needs to be on Python's import
|
||||||
* ``module``: The WSGI module to use, probably the ``mysite.wsgi`` module which
|
path -- i.e., the directory containing the ``mysite`` package.
|
||||||
:djadmin:`startproject` creates.
|
* ``module``: The WSGI module to use -- probably the ``mysite.wsgi`` module
|
||||||
* ``env``: should probably contain at least ``DJANGO_SETTINGS_MODULE``
|
that :djadmin:`startproject` creates.
|
||||||
* ``home``: optional path to your project virtualenv
|
* ``env``: Should probably contain at least ``DJANGO_SETTINGS_MODULE``.
|
||||||
|
* ``home``: Optional path to your project virtualenv.
|
||||||
|
|
||||||
Example ini configuration file::
|
Example ini configuration file::
|
||||||
|
|
||||||
|
@ -89,8 +90,7 @@ Example ini configuration file usage::
|
||||||
|
|
||||||
uwsgi --ini uwsgi.ini
|
uwsgi --ini uwsgi.ini
|
||||||
|
|
||||||
|
|
||||||
See the uWSGI docs on `managing the uWSGI process`_ for information on
|
See the uWSGI docs on `managing the uWSGI process`_ for information on
|
||||||
starting, stoping, and reloading the uWSGI workers.
|
starting, stoping and reloading the uWSGI workers.
|
||||||
|
|
||||||
.. _managing the uWSGI process: http://projects.unbit.it/uwsgi/wiki/Management
|
.. _managing the uWSGI process: http://projects.unbit.it/uwsgi/wiki/Management
|
||||||
|
|
|
@ -69,10 +69,10 @@ You'll store this data in a ``fixtures`` directory inside your app.
|
||||||
|
|
||||||
Loading data is easy: just call :djadmin:`manage.py loaddata <fixturename>
|
Loading data is easy: just call :djadmin:`manage.py loaddata <fixturename>
|
||||||
<loaddata>`, where ``<fixturename>`` is the name of the fixture file you've
|
<loaddata>`, where ``<fixturename>`` is the name of the fixture file you've
|
||||||
created. Every time you run :djadmin:`loaddata` the data will be read from the
|
created. Each time you run :djadmin:`loaddata`, the data will be read from the
|
||||||
fixture and re-loaded into the database. Note that this means that if you
|
fixture and re-loaded into the database. Note this means that if you change one
|
||||||
change one of the rows created by a fixture and then run :djadmin:`loaddata`
|
of the rows created by a fixture and then run :djadmin:`loaddata` again, you'll
|
||||||
again you'll wipe out any changes you've made.
|
wipe out any changes you've made.
|
||||||
|
|
||||||
Automatically loading initial data fixtures
|
Automatically loading initial data fixtures
|
||||||
-------------------------------------------
|
-------------------------------------------
|
||||||
|
|
|
@ -222,7 +222,8 @@ your database connection settings.
|
||||||
If you're new to databases, we recommend simply using SQLite by setting
|
If you're new to databases, we recommend simply using SQLite by setting
|
||||||
:setting:`ENGINE` to ``'django.db.backends.sqlite3'`` and :setting:`NAME` to
|
:setting:`ENGINE` to ``'django.db.backends.sqlite3'`` and :setting:`NAME` to
|
||||||
the place where you'd like to store the database. SQLite is included as part
|
the place where you'd like to store the database. SQLite is included as part
|
||||||
of Python 2.5 and later, so you won't need to install anything else.
|
of Python 2.5 and later, so you won't need to install anything else to support
|
||||||
|
your database.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
|
@ -234,11 +235,10 @@ of Python 2.5 and later, so you won't need to install anything else.
|
||||||
database file will be created automatically when it is needed.
|
database file will be created automatically when it is needed.
|
||||||
|
|
||||||
While you're editing :file:`settings.py`, set :setting:`TIME_ZONE` to your
|
While you're editing :file:`settings.py`, set :setting:`TIME_ZONE` to your
|
||||||
time zone. The default value isn't correct for you, unless you happen to live
|
time zone. The default value is the Central time zone in the U.S. (Chicago).
|
||||||
near Chicago.
|
|
||||||
|
|
||||||
Also, take note of the :setting:`INSTALLED_APPS` setting towards the bottom of
|
Also, note the :setting:`INSTALLED_APPS` setting toward the bottom of
|
||||||
the file. That variable holds the names of all Django applications that are
|
the file. That holds the names of all Django applications that are
|
||||||
activated in this Django instance. Apps can be used in multiple projects, and
|
activated in this Django instance. Apps can be used in multiple projects, and
|
||||||
you can package and distribute them for use by others in their projects.
|
you can package and distribute them for use by others in their projects.
|
||||||
|
|
||||||
|
@ -510,10 +510,10 @@ Now, run :djadmin:`syncdb` again to create those model tables in your database:
|
||||||
|
|
||||||
python manage.py syncdb
|
python manage.py syncdb
|
||||||
|
|
||||||
The :djadmin:`syncdb` command runs the sql from :djadmin:`sqlall` on your
|
The :djadmin:`syncdb` command runs the SQL from :djadmin:`sqlall` on your
|
||||||
database for all apps in :setting:`INSTALLED_APPS` that don't already exist in
|
database for all apps in :setting:`INSTALLED_APPS` that don't already exist in
|
||||||
your database. This creates all the tables, initial data and indexes for any
|
your database. This creates all the tables, initial data and indexes for any
|
||||||
apps you have added to your project since the last time you ran syncdb.
|
apps you've added to your project since the last time you ran syncdb.
|
||||||
:djadmin:`syncdb` can be called as often as you like, and it will only ever
|
:djadmin:`syncdb` can be called as often as you like, and it will only ever
|
||||||
create the tables that don't exist.
|
create the tables that don't exist.
|
||||||
|
|
||||||
|
@ -638,7 +638,7 @@ demonstration::
|
||||||
|
|
||||||
Note the addition of ``import datetime`` and ``from django.utils import
|
Note the addition of ``import datetime`` and ``from django.utils import
|
||||||
timezone``, to reference Python's standard :mod:`datetime` module and Django's
|
timezone``, to reference Python's standard :mod:`datetime` module and Django's
|
||||||
time zone-related utilities in :mod:`django.utils.timezone` respectively. If
|
time-zone-related utilities in :mod:`django.utils.timezone`, respectively. If
|
||||||
you aren't familiar with time zone handling in Python, you can learn more in
|
you aren't familiar with time zone handling in Python, you can learn more in
|
||||||
the :doc:`time zone support docs </topics/i18n/timezones>`.
|
the :doc:`time zone support docs </topics/i18n/timezones>`.
|
||||||
|
|
||||||
|
|
|
@ -18,7 +18,7 @@ automatically-generated admin site.
|
||||||
displayed on the public site. Django solves the problem of creating a
|
displayed on the public site. Django solves the problem of creating a
|
||||||
unified interface for site administrators to edit content.
|
unified interface for site administrators to edit content.
|
||||||
|
|
||||||
The admin isn't intended to be used by site visitors; it's for site
|
The admin isn't intended to be used by site visitors. It's for site
|
||||||
managers.
|
managers.
|
||||||
|
|
||||||
Activate the admin site
|
Activate the admin site
|
||||||
|
@ -171,7 +171,7 @@ The bottom part of the page gives you a couple of options:
|
||||||
|
|
||||||
If the value of "Date published" doesn't match the time when you created the
|
If the value of "Date published" doesn't match the time when you created the
|
||||||
poll in Tutorial 1, it probably means you forgot to set the correct value for
|
poll in Tutorial 1, it probably means you forgot to set the correct value for
|
||||||
the :setting:`TIME_ZONE` setting. Change it, reload the page, and check that
|
the :setting:`TIME_ZONE` setting. Change it, reload the page and check that
|
||||||
the correct value appears.
|
the correct value appears.
|
||||||
|
|
||||||
Change the "Date published" by clicking the "Today" and "Now" shortcuts. Then
|
Change the "Date published" by clicking the "Today" and "Now" shortcuts. Then
|
||||||
|
|
|
@ -155,13 +155,13 @@ MySQL has several `storage engines`_ (previously called table types). You can
|
||||||
change the default storage engine in the server configuration.
|
change the default storage engine in the server configuration.
|
||||||
|
|
||||||
Until MySQL 5.5.4, the default engine was MyISAM_ [#]_. The main drawbacks of
|
Until MySQL 5.5.4, the default engine was MyISAM_ [#]_. The main drawbacks of
|
||||||
MyISAM are that it doesn't support transactions or enforce foreign keys
|
MyISAM are that it doesn't support transactions or enforce foreign-key
|
||||||
constraints. On the plus side, it's currently the only engine that supports
|
constraints. On the plus side, it's currently the only engine that supports
|
||||||
full-text indexing and searching.
|
full-text indexing and searching.
|
||||||
|
|
||||||
Since MySQL 5.5.5, the default storage engine is InnoDB_. This engine is fully
|
Since MySQL 5.5.5, the default storage engine is InnoDB_. This engine is fully
|
||||||
transactional and supports foreign key references. It's probably the best
|
transactional and supports foreign key references. It's probably the best
|
||||||
choice at this point in time.
|
choice at this point.
|
||||||
|
|
||||||
.. versionchanged:: 1.4
|
.. versionchanged:: 1.4
|
||||||
|
|
||||||
|
|
|
@ -379,8 +379,8 @@ installation will be aborted, and any data installed in the call to
|
||||||
.. admonition:: MySQL with MyISAM and fixtures
|
.. admonition:: MySQL with MyISAM and fixtures
|
||||||
|
|
||||||
The MyISAM storage engine of MySQL doesn't support transactions or
|
The MyISAM storage engine of MySQL doesn't support transactions or
|
||||||
constraints, so you won't get a rollback if multiple transaction files are
|
constraints, so if you use MyISAM, you won't get validation of fixture
|
||||||
found, or validation of fixture data, if you use MyISAM tables.
|
data, or a rollback if multiple transaction files are found.
|
||||||
|
|
||||||
Database-specific fixtures
|
Database-specific fixtures
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
|
@ -228,8 +228,8 @@ Methods
|
||||||
parts = request.META[field].split(',')
|
parts = request.META[field].split(',')
|
||||||
request.META[field] = parts[-1].strip()
|
request.META[field] = parts[-1].strip()
|
||||||
|
|
||||||
This middleware should be positionned before any other middleware that
|
This middleware should be positioned before any other middleware that
|
||||||
relies on the value of :meth:`~HttpRequest.get_host()`, for instance
|
relies on the value of :meth:`~HttpRequest.get_host()` -- for instance,
|
||||||
:class:`~django.middleware.common.CommonMiddleware` or
|
:class:`~django.middleware.common.CommonMiddleware` or
|
||||||
:class:`~django.middleware.csrf.CsrfViewMiddleware`.
|
:class:`~django.middleware.csrf.CsrfViewMiddleware`.
|
||||||
|
|
||||||
|
|
|
@ -9,9 +9,9 @@ Settings
|
||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
Be careful when you override settings, especially when the default value
|
Be careful when you override settings, especially when the default value
|
||||||
is a non-empty tuple or dict, like :setting:`MIDDLEWARE_CLASSES` and
|
is a non-empty tuple or dictionary, such as :setting:`MIDDLEWARE_CLASSES`
|
||||||
:setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the components
|
and :setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the
|
||||||
required by the features of Django you wish to use.
|
components required by the features of Django you wish to use.
|
||||||
|
|
||||||
Available settings
|
Available settings
|
||||||
==================
|
==================
|
||||||
|
@ -705,9 +705,9 @@ Default::
|
||||||
'%B %d, %Y', '%d %B %Y', '%d %B, %Y')
|
'%B %d, %Y', '%d %B %Y', '%d %B, %Y')
|
||||||
|
|
||||||
A tuple of formats that will be accepted when inputting data on a date field.
|
A tuple of formats that will be accepted when inputting data on a date field.
|
||||||
Formats will be tried in order, using the first valid. Note that these format
|
Formats will be tried in order, using the first valid one. Note that these
|
||||||
strings are specified in Python's datetime_ module syntax, that is different
|
format strings use Python's datetime_ module syntax, not the format strings
|
||||||
from the one used by Django for formatting dates to be displayed.
|
from the ``date`` Django template tag.
|
||||||
|
|
||||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||||
precedence and will be applied instead.
|
precedence and will be applied instead.
|
||||||
|
@ -747,9 +747,9 @@ Default::
|
||||||
'%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M', '%m/%d/%y')
|
'%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M', '%m/%d/%y')
|
||||||
|
|
||||||
A tuple of formats that will be accepted when inputting data on a datetime
|
A tuple of formats that will be accepted when inputting data on a datetime
|
||||||
field. Formats will be tried in order, using the first valid. Note that these
|
field. Formats will be tried in order, using the first valid one. Note that
|
||||||
format strings are specified in Python's datetime_ module syntax, that is
|
these format strings use Python's datetime_ module syntax, not the format
|
||||||
different from the one used by Django for formatting dates to be displayed.
|
strings from the ``date`` Django template tag.
|
||||||
|
|
||||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||||
precedence and will be applied instead.
|
precedence and will be applied instead.
|
||||||
|
@ -2082,9 +2082,9 @@ TIME_INPUT_FORMATS
|
||||||
Default: ``('%H:%M:%S', '%H:%M')``
|
Default: ``('%H:%M:%S', '%H:%M')``
|
||||||
|
|
||||||
A tuple of formats that will be accepted when inputting data on a time field.
|
A tuple of formats that will be accepted when inputting data on a time field.
|
||||||
Formats will be tried in order, using the first valid. Note that these format
|
Formats will be tried in order, using the first valid one. Note that these
|
||||||
strings are specified in Python's datetime_ module syntax, that is different
|
format strings use Python's datetime_ module syntax, not the format strings
|
||||||
from the one used by Django for formatting dates to be displayed.
|
from the ``date`` Django template tag.
|
||||||
|
|
||||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||||
precedence and will be applied instead.
|
precedence and will be applied instead.
|
||||||
|
|
|
@ -600,8 +600,8 @@ For a complete discussion on the usage of the following see the
|
||||||
requests a sublanguage where we have a main language, we send out the main
|
requests a sublanguage where we have a main language, we send out the main
|
||||||
language.
|
language.
|
||||||
|
|
||||||
If ``check_path`` is ``True`` the function first checks the requested URL
|
If ``check_path`` is ``True``, the function first checks the requested URL
|
||||||
whether its path begins with a language code listed in the
|
for whether its path begins with a language code listed in the
|
||||||
:setting:`LANGUAGES` setting.
|
:setting:`LANGUAGES` setting.
|
||||||
|
|
||||||
.. function:: to_locale(language)
|
.. function:: to_locale(language)
|
||||||
|
|
|
@ -621,8 +621,8 @@ SECRET_KEY setting is required
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Running Django with an empty or known :setting:`SECRET_KEY` disables many of
|
Running Django with an empty or known :setting:`SECRET_KEY` disables many of
|
||||||
Django's security protections, and can lead to remote-code-execution
|
Django's security protections and can lead to remote-code-execution
|
||||||
vulnerabilities; no Django site should ever be run without a
|
vulnerabilities. No Django site should ever be run without a
|
||||||
:setting:`SECRET_KEY`.
|
:setting:`SECRET_KEY`.
|
||||||
|
|
||||||
In Django 1.4, starting Django with an empty :setting:`SECRET_KEY` will raise a
|
In Django 1.4, starting Django with an empty :setting:`SECRET_KEY` will raise a
|
||||||
|
@ -631,7 +631,6 @@ refuse to start. This is slightly accelerated from the usual deprecation path
|
||||||
due to the severity of the consequences of running Django with no
|
due to the severity of the consequences of running Django with no
|
||||||
:setting:`SECRET_KEY`.
|
:setting:`SECRET_KEY`.
|
||||||
|
|
||||||
|
|
||||||
django.contrib.admin
|
django.contrib.admin
|
||||||
~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -1000,7 +999,7 @@ Session cookies now have the ``httponly`` flag by default
|
||||||
Session cookies now include the ``httponly`` attribute by default to
|
Session cookies now include the ``httponly`` attribute by default to
|
||||||
help reduce the impact of potential XSS attacks. As a consequence of
|
help reduce the impact of potential XSS attacks. As a consequence of
|
||||||
this change, session cookie data, including sessionid, is no longer
|
this change, session cookie data, including sessionid, is no longer
|
||||||
accessible from Javascript in many browsers. For strict backwards
|
accessible from JavaScript in many browsers. For strict backwards
|
||||||
compatibility, use ``SESSION_COOKIE_HTTPONLY = False`` in your
|
compatibility, use ``SESSION_COOKIE_HTTPONLY = False`` in your
|
||||||
settings file.
|
settings file.
|
||||||
|
|
||||||
|
@ -1055,11 +1054,11 @@ management commands in a script, use
|
||||||
|
|
||||||
Previously, the :ttag:`extends` tag used a buggy method of parsing arguments,
|
Previously, the :ttag:`extends` tag used a buggy method of parsing arguments,
|
||||||
which could lead to it erroneously considering an argument as a string literal
|
which could lead to it erroneously considering an argument as a string literal
|
||||||
when it wasn't. It now utilises ``parser.compile_filter`` like other tags.
|
when it wasn't. It now uses ``parser.compile_filter``, like other tags.
|
||||||
|
|
||||||
The internals of the tag aren't part of the official stable API, but in the
|
The internals of the tag aren't part of the official stable API, but in the
|
||||||
interests of full disclosure, the ``ExtendsNode.__init__`` definition has
|
interests of full disclosure, the ``ExtendsNode.__init__`` definition has
|
||||||
changed which may break any custom tags that use this node class.
|
changed, which may break any custom tags that use this class.
|
||||||
|
|
||||||
Features deprecated in 1.4
|
Features deprecated in 1.4
|
||||||
==========================
|
==========================
|
||||||
|
|
|
@ -1461,9 +1461,9 @@ The permission_required decorator
|
||||||
Limiting access to generic views
|
Limiting access to generic views
|
||||||
--------------------------------
|
--------------------------------
|
||||||
|
|
||||||
Controlling access to a :doc:`class-based generic view </ref/class-based-views>`
|
To limit access to a :doc:`class-based generic view </ref/class-based-views>`,
|
||||||
is done by decorating the :meth:`View.dispatch <django.views.generic.base.View.dispatch>`
|
decorate the :meth:`View.dispatch <django.views.generic.base.View.dispatch>`
|
||||||
method on the class. See :ref:`decorating-class-based-views` for the details.
|
method on the class. See :ref:`decorating-class-based-views` for details.
|
||||||
|
|
||||||
Function-based generic views
|
Function-based generic views
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
|
@ -76,7 +76,7 @@ The :meth:`~django.db.models.Model.save` method has no return value.
|
||||||
described here. See the documentation for
|
described here. See the documentation for
|
||||||
:meth:`~django.db.models.Model.save` for complete details.
|
:meth:`~django.db.models.Model.save` for complete details.
|
||||||
|
|
||||||
To create an object and save it all in one step see the
|
To create and save an object in a single step, use the
|
||||||
:meth:`~django.db.models.query.QuerySet.create()` method.
|
:meth:`~django.db.models.query.QuerySet.create()` method.
|
||||||
|
|
||||||
Saving changes to objects
|
Saving changes to objects
|
||||||
|
@ -98,9 +98,9 @@ Saving ``ForeignKey`` and ``ManyToManyField`` fields
|
||||||
----------------------------------------------------
|
----------------------------------------------------
|
||||||
|
|
||||||
Updating a :class:`~django.db.models.ForeignKey` field works exactly the same
|
Updating a :class:`~django.db.models.ForeignKey` field works exactly the same
|
||||||
way as saving a normal field; simply assign an object of the right type to the
|
way as saving a normal field -- simply assign an object of the right type to
|
||||||
field in question. This example updates the ``blog`` attribute of an ``Entry``
|
the field in question. This example updates the ``blog`` attribute of an
|
||||||
instance ``entry``::
|
``Entry`` instance ``entry``::
|
||||||
|
|
||||||
>>> from blog.models import Entry
|
>>> from blog.models import Entry
|
||||||
>>> entry = Entry.objects.get(pk=1)
|
>>> entry = Entry.objects.get(pk=1)
|
||||||
|
@ -109,7 +109,7 @@ instance ``entry``::
|
||||||
>>> entry.save()
|
>>> entry.save()
|
||||||
|
|
||||||
Updating a :class:`~django.db.models.ManyToManyField` works a little
|
Updating a :class:`~django.db.models.ManyToManyField` works a little
|
||||||
differently; use the
|
differently -- use the
|
||||||
:meth:`~django.db.models.fields.related.RelatedManager.add` method on the field
|
:meth:`~django.db.models.fields.related.RelatedManager.add` method on the field
|
||||||
to add a record to the relation. This example adds the ``Author`` instance
|
to add a record to the relation. This example adds the ``Author`` instance
|
||||||
``joe`` to the ``entry`` object::
|
``joe`` to the ``entry`` object::
|
||||||
|
@ -133,7 +133,7 @@ Django will complain if you try to assign or add an object of the wrong type.
|
||||||
Retrieving objects
|
Retrieving objects
|
||||||
==================
|
==================
|
||||||
|
|
||||||
To retrieve objects from your database, you construct a
|
To retrieve objects from your database, construct a
|
||||||
:class:`~django.db.models.query.QuerySet` via a
|
:class:`~django.db.models.query.QuerySet` via a
|
||||||
:class:`~django.db.models.Manager` on your model class.
|
:class:`~django.db.models.Manager` on your model class.
|
||||||
|
|
||||||
|
|
|
@ -1477,13 +1477,13 @@ decorate the class::
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
When overriding settings make sure to also handle the cases in which your
|
When overriding settings, make sure to handle the cases in which your app's
|
||||||
app's code uses a cache or similar feature that retains state even if the
|
code uses a cache or similar feature that retains state even if the
|
||||||
setting is changed. Django provides the
|
setting is changed. Django provides the
|
||||||
:data:`django.test.signals.setting_changed` signal to connect cleanup and
|
:data:`django.test.signals.setting_changed` signal that lets you register
|
||||||
other state-resetting callbacks to. Note that this signal isn't currently
|
callbacks to clean up and otherwise reset state when settings are changed.
|
||||||
used by Django itself, so changing built-in settings may not yield the
|
Note that this signal isn't currently used by Django itself, so changing
|
||||||
results you expect.
|
built-in settings may not yield the results you expect.
|
||||||
|
|
||||||
Emptying the test outbox
|
Emptying the test outbox
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
|
@ -508,7 +508,7 @@ class AdminViewBasicTest(TestCase):
|
||||||
|
|
||||||
def testI18NLanguageNonEnglishDefault(self):
|
def testI18NLanguageNonEnglishDefault(self):
|
||||||
"""
|
"""
|
||||||
Check if the Javascript i18n view returns an empty language catalog
|
Check if the JavaScript i18n view returns an empty language catalog
|
||||||
if the default language is non-English but the selected language
|
if the default language is non-English but the selected language
|
||||||
is English. See #13388 and #3594 for more details.
|
is English. See #13388 and #3594 for more details.
|
||||||
"""
|
"""
|
||||||
|
@ -529,7 +529,7 @@ class AdminViewBasicTest(TestCase):
|
||||||
|
|
||||||
def testL10NDeactivated(self):
|
def testL10NDeactivated(self):
|
||||||
"""
|
"""
|
||||||
Check if L10N is deactivated, the Javascript i18n view doesn't
|
Check if L10N is deactivated, the JavaScript i18n view doesn't
|
||||||
return localized date/time formats. Refs #14824.
|
return localized date/time formats. Refs #14824.
|
||||||
"""
|
"""
|
||||||
with self.settings(LANGUAGE_CODE='ru', USE_L10N=False):
|
with self.settings(LANGUAGE_CODE='ru', USE_L10N=False):
|
||||||
|
@ -2862,7 +2862,7 @@ class NeverCacheTests(TestCase):
|
||||||
self.assertEqual(get_max_age(response), None)
|
self.assertEqual(get_max_age(response), None)
|
||||||
|
|
||||||
def testJsi18n(self):
|
def testJsi18n(self):
|
||||||
"Check the never-cache status of the Javascript i18n view"
|
"Check the never-cache status of the JavaScript i18n view"
|
||||||
response = self.client.get('/test_admin/admin/jsi18n/')
|
response = self.client.get('/test_admin/admin/jsi18n/')
|
||||||
self.assertEqual(get_max_age(response), None)
|
self.assertEqual(get_max_age(response), None)
|
||||||
|
|
||||||
|
@ -2896,7 +2896,7 @@ class PrePopulatedTest(TestCase):
|
||||||
def test_prepopulated_maxlength_localized(self):
|
def test_prepopulated_maxlength_localized(self):
|
||||||
"""
|
"""
|
||||||
Regression test for #15938: if USE_THOUSAND_SEPARATOR is set, make sure
|
Regression test for #15938: if USE_THOUSAND_SEPARATOR is set, make sure
|
||||||
that maxLength (in the javascript) is rendered without separators.
|
that maxLength (in the JavaScript) is rendered without separators.
|
||||||
"""
|
"""
|
||||||
response = self.client.get('/test_admin/admin/admin_views/prepopulatedpostlargeslug/add/')
|
response = self.client.get('/test_admin/admin/admin_views/prepopulatedpostlargeslug/add/')
|
||||||
self.assertContains(response, "maxLength: 1000") # instead of 1,000
|
self.assertContains(response, "maxLength: 1000") # instead of 1,000
|
||||||
|
@ -2909,7 +2909,7 @@ class SeleniumPrePopulatedFirefoxTests(AdminSeleniumWebDriverTestCase):
|
||||||
|
|
||||||
def test_basic(self):
|
def test_basic(self):
|
||||||
"""
|
"""
|
||||||
Ensure that the Javascript-automated prepopulated fields work with the
|
Ensure that the JavaScript-automated prepopulated fields work with the
|
||||||
main form and with stacked and tabular inlines.
|
main form and with stacked and tabular inlines.
|
||||||
Refs #13068, #9264, #9983, #9784.
|
Refs #13068, #9264, #9983, #9784.
|
||||||
"""
|
"""
|
||||||
|
|
Loading…
Reference in New Issue