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):
|
||||
|
||||
def test01_update(self):
|
||||
"Testing GeoQuerySet.update(), see #10411."
|
||||
"Testing GeoQuerySet.update(). See #10411."
|
||||
pnt = City.objects.get(name='Pueblo').point
|
||||
bak = pnt.clone()
|
||||
pnt.y += 0.005
|
||||
|
@ -25,7 +25,7 @@ class GeoRegressionTests(TestCase):
|
|||
self.assertEqual(bak, City.objects.get(name='Pueblo').point)
|
||||
|
||||
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')
|
||||
places = [{'name' : name,
|
||||
'description' : name,
|
||||
|
@ -36,7 +36,7 @@ class GeoRegressionTests(TestCase):
|
|||
@no_spatialite
|
||||
@no_mysql
|
||||
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
|
||||
ref_ext = (pnt.x, pnt.y, pnt.x, pnt.y)
|
||||
extent = City.objects.filter(name='Pueblo').extent()
|
||||
|
@ -44,14 +44,14 @@ class GeoRegressionTests(TestCase):
|
|||
self.assertAlmostEqual(ref_val, val, 4)
|
||||
|
||||
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)
|
||||
mansfield = PennsylvaniaCity.objects.create(name='Mansfield', county='Tioga', point='POINT(-77.071445 41.823881)',
|
||||
founded=founded)
|
||||
self.assertEqual(founded, PennsylvaniaCity.objects.dates('founded', 'day')[0])
|
||||
|
||||
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
|
||||
pueblo = City.objects.get(name='Pueblo')
|
||||
state = State.objects.filter(poly__contains=pueblo.point)
|
||||
|
@ -61,6 +61,6 @@ class GeoRegressionTests(TestCase):
|
|||
self.assertEqual(cities_within_state.count(), 1)
|
||||
|
||||
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')).only('name')), list)
|
||||
|
|
|
@ -40,15 +40,15 @@ class Options(object):
|
|||
self.abstract = False
|
||||
self.managed = True
|
||||
self.proxy = False
|
||||
# For any class which is a proxy (including automatically created
|
||||
# classes for deferred object loading) the proxy_for_model tells
|
||||
# For any class that is a proxy (including automatically created
|
||||
# classes for deferred object loading), proxy_for_model tells us
|
||||
# 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.
|
||||
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
|
||||
# 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.parents = SortedDict()
|
||||
self.duplicate_targets = {}
|
||||
|
|
|
@ -12,14 +12,14 @@ container server coded in pure C.
|
|||
Prerequisite: uWSGI
|
||||
===================
|
||||
|
||||
The wiki describes several `installation procedures`_. Using pip, the python
|
||||
package manager, installing any uWSGI version can be done with one command
|
||||
line. For example::
|
||||
The uWSGI wiki describes several `installation procedures`_. Using pip, the
|
||||
Python package manager, you can install any uWSGI version with a single
|
||||
command. For example::
|
||||
|
||||
# install current stable version
|
||||
# Install current stable version.
|
||||
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
|
||||
|
||||
.. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
|
||||
|
@ -27,7 +27,7 @@ line. For example::
|
|||
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.
|
||||
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
|
||||
----------------------------------------------------
|
||||
|
||||
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: http://projects.unbit.it/uwsgi/wiki/Doc
|
||||
.. _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
|
||||
--module='mysite.wsgi:application' \
|
||||
|
@ -52,27 +52,28 @@ An example command to start a uWSGI server::
|
|||
--processes=5 \ # number of worker processes
|
||||
--uid=1000 --gid=2000 \ # if root, uwsgi can drop privileges
|
||||
--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
|
||||
--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
|
||||
|
||||
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``
|
||||
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
|
||||
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
|
||||
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:
|
||||
|
||||
* ``chdir``: the path to the directory that needs to be on Python's import path; i.e. the directory containing the ``mysite`` package.
|
||||
* ``module``: The WSGI module to use, probably the ``mysite.wsgi`` module which
|
||||
:djadmin:`startproject` creates.
|
||||
* ``env``: should probably contain at least ``DJANGO_SETTINGS_MODULE``
|
||||
* ``home``: optional path to your project virtualenv
|
||||
* ``chdir``: The path to the directory that needs to be on Python's import
|
||||
path -- i.e., the directory containing the ``mysite`` package.
|
||||
* ``module``: The WSGI module to use -- probably the ``mysite.wsgi`` module
|
||||
that :djadmin:`startproject` creates.
|
||||
* ``env``: Should probably contain at least ``DJANGO_SETTINGS_MODULE``.
|
||||
* ``home``: Optional path to your project virtualenv.
|
||||
|
||||
Example ini configuration file::
|
||||
|
||||
|
@ -89,8 +90,7 @@ Example ini configuration file usage::
|
|||
|
||||
uwsgi --ini uwsgi.ini
|
||||
|
||||
|
||||
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
|
||||
|
|
|
@ -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>
|
||||
<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
|
||||
fixture and re-loaded into the database. Note that this means that if you
|
||||
change one of the rows created by a fixture and then run :djadmin:`loaddata`
|
||||
again you'll wipe out any changes you've made.
|
||||
created. Each time you run :djadmin:`loaddata`, the data will be read from the
|
||||
fixture and re-loaded into the database. Note this means that if you change one
|
||||
of the rows created by a fixture and then run :djadmin:`loaddata` again, you'll
|
||||
wipe out any changes you've made.
|
||||
|
||||
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
|
||||
: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
|
||||
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::
|
||||
|
||||
|
@ -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.
|
||||
|
||||
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
|
||||
near Chicago.
|
||||
time zone. The default value is the Central time zone in the U.S. (Chicago).
|
||||
|
||||
Also, take note of the :setting:`INSTALLED_APPS` setting towards the bottom of
|
||||
the file. That variable holds the names of all Django applications that are
|
||||
Also, note the :setting:`INSTALLED_APPS` setting toward the bottom of
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
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
|
||||
create the tables that don't exist.
|
||||
|
||||
|
@ -638,7 +638,7 @@ demonstration::
|
|||
|
||||
Note the addition of ``import datetime`` and ``from django.utils import
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
full-text indexing and searching.
|
||||
|
||||
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
|
||||
choice at this point in time.
|
||||
choice at this point.
|
||||
|
||||
.. 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
|
||||
|
||||
The MyISAM storage engine of MySQL doesn't support transactions or
|
||||
constraints, so you won't get a rollback if multiple transaction files are
|
||||
found, or validation of fixture data, if you use MyISAM tables.
|
||||
constraints, so if you use MyISAM, you won't get validation of fixture
|
||||
data, or a rollback if multiple transaction files are found.
|
||||
|
||||
Database-specific fixtures
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -228,8 +228,8 @@ Methods
|
|||
parts = request.META[field].split(',')
|
||||
request.META[field] = parts[-1].strip()
|
||||
|
||||
This middleware should be positionned before any other middleware that
|
||||
relies on the value of :meth:`~HttpRequest.get_host()`, for instance
|
||||
This middleware should be positioned before any other middleware that
|
||||
relies on the value of :meth:`~HttpRequest.get_host()` -- for instance,
|
||||
:class:`~django.middleware.common.CommonMiddleware` or
|
||||
:class:`~django.middleware.csrf.CsrfViewMiddleware`.
|
||||
|
||||
|
|
|
@ -9,9 +9,9 @@ Settings
|
|||
.. warning::
|
||||
|
||||
Be careful when you override settings, especially when the default value
|
||||
is a non-empty tuple or dict, like :setting:`MIDDLEWARE_CLASSES` and
|
||||
:setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the components
|
||||
required by the features of Django you wish to use.
|
||||
is a non-empty tuple or dictionary, such as :setting:`MIDDLEWARE_CLASSES`
|
||||
and :setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the
|
||||
components required by the features of Django you wish to use.
|
||||
|
||||
Available settings
|
||||
==================
|
||||
|
@ -705,9 +705,9 @@ Default::
|
|||
'%B %d, %Y', '%d %B %Y', '%d %B, %Y')
|
||||
|
||||
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
|
||||
strings are specified in Python's datetime_ module syntax, that is different
|
||||
from the one used by Django for formatting dates to be displayed.
|
||||
Formats will be tried in order, using the first valid one. Note that these
|
||||
format strings use Python's datetime_ module syntax, not the format strings
|
||||
from the ``date`` Django template tag.
|
||||
|
||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||
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')
|
||||
|
||||
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
|
||||
format strings are specified in Python's datetime_ module syntax, that is
|
||||
different from the one used by Django for formatting dates to be displayed.
|
||||
field. Formats will be tried in order, using the first valid one. Note that
|
||||
these format strings use Python's datetime_ module syntax, not the format
|
||||
strings from the ``date`` Django template tag.
|
||||
|
||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||
precedence and will be applied instead.
|
||||
|
@ -1344,7 +1344,7 @@ decorator, for example.
|
|||
.. note::
|
||||
You can use :func:`~django.core.urlresolvers.reverse_lazy` to reference
|
||||
URLs by their name instead of providing a hardcoded value. Assuming a
|
||||
``urls.py`` with an URL pattern named ``home``::
|
||||
``urls.py`` with an URLpattern named ``home``::
|
||||
|
||||
urlpatterns = patterns('',
|
||||
url('^welcome/$', 'test_app.views.home', name='home'),
|
||||
|
@ -2082,9 +2082,9 @@ TIME_INPUT_FORMATS
|
|||
Default: ``('%H:%M:%S', '%H:%M')``
|
||||
|
||||
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
|
||||
strings are specified in Python's datetime_ module syntax, that is different
|
||||
from the one used by Django for formatting dates to be displayed.
|
||||
Formats will be tried in order, using the first valid one. Note that these
|
||||
format strings use Python's datetime_ module syntax, not the format strings
|
||||
from the ``date`` Django template tag.
|
||||
|
||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||
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
|
||||
language.
|
||||
|
||||
If ``check_path`` is ``True`` the function first checks the requested URL
|
||||
whether its path begins with a language code listed in the
|
||||
If ``check_path`` is ``True``, the function first checks the requested URL
|
||||
for whether its path begins with a language code listed in the
|
||||
:setting:`LANGUAGES` setting.
|
||||
|
||||
.. 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
|
||||
Django's security protections, and can lead to remote-code-execution
|
||||
vulnerabilities; no Django site should ever be run without a
|
||||
Django's security protections and can lead to remote-code-execution
|
||||
vulnerabilities. No Django site should ever be run without a
|
||||
:setting:`SECRET_KEY`.
|
||||
|
||||
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
|
||||
:setting:`SECRET_KEY`.
|
||||
|
||||
|
||||
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
|
||||
help reduce the impact of potential XSS attacks. As a consequence of
|
||||
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
|
||||
settings file.
|
||||
|
||||
|
@ -1055,11 +1054,11 @@ management commands in a script, use
|
|||
|
||||
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
|
||||
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
|
||||
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
|
||||
==========================
|
||||
|
|
|
@ -1461,9 +1461,9 @@ The permission_required decorator
|
|||
Limiting access to generic views
|
||||
--------------------------------
|
||||
|
||||
Controlling 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>`
|
||||
method on the class. See :ref:`decorating-class-based-views` for the details.
|
||||
To limit access to a :doc:`class-based generic view </ref/class-based-views>`,
|
||||
decorate the :meth:`View.dispatch <django.views.generic.base.View.dispatch>`
|
||||
method on the class. See :ref:`decorating-class-based-views` for details.
|
||||
|
||||
Function-based generic views
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -73,10 +73,10 @@ The :meth:`~django.db.models.Model.save` method has no return value.
|
|||
.. seealso::
|
||||
|
||||
:meth:`~django.db.models.Model.save` takes a number of advanced options not
|
||||
described here. See the documentation for
|
||||
described here. See the documentation for
|
||||
: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.
|
||||
|
||||
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
|
||||
way as saving a normal field; simply assign an object of the right type to the
|
||||
field in question. This example updates the ``blog`` attribute of an ``Entry``
|
||||
instance ``entry``::
|
||||
way as saving a normal field -- simply assign an object of the right type to
|
||||
the field in question. This example updates the ``blog`` attribute of an
|
||||
``Entry`` instance ``entry``::
|
||||
|
||||
>>> from blog.models import Entry
|
||||
>>> entry = Entry.objects.get(pk=1)
|
||||
|
@ -109,7 +109,7 @@ instance ``entry``::
|
|||
>>> entry.save()
|
||||
|
||||
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
|
||||
to add a record to the relation. This example adds the ``Author`` instance
|
||||
``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
|
||||
==================
|
||||
|
||||
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.Manager` on your model class.
|
||||
|
||||
|
@ -164,14 +164,14 @@ default. Access it directly via the model class, like so::
|
|||
|
||||
The :class:`~django.db.models.Manager` is the main source of ``QuerySets`` for
|
||||
a model. It acts as a "root" :class:`~django.db.models.query.QuerySet` that
|
||||
describes all objects in the model's database table. For example,
|
||||
describes all objects in the model's database table. For example,
|
||||
``Blog.objects`` is the initial :class:`~django.db.models.query.QuerySet` that
|
||||
contains all ``Blog`` objects in the database.
|
||||
|
||||
Retrieving all objects
|
||||
----------------------
|
||||
|
||||
The simplest way to retrieve objects from a table is to get all of them. To do
|
||||
The simplest way to retrieve objects from a table is to get all of them. To do
|
||||
this, use the :meth:`~django.db.models.query.QuerySet.all` method on a
|
||||
:class:`~django.db.models.Manager`::
|
||||
|
||||
|
@ -551,7 +551,7 @@ entry that contains a tag with a name of *"music"* and a status of *"public"*.
|
|||
|
||||
To handle both of these situations, Django has a consistent way of processing
|
||||
:meth:`~django.db.models.query.QuerySet.filter` and
|
||||
:meth:`~django.db.models.query.QuerySet.exclude` calls. Everything inside a
|
||||
:meth:`~django.db.models.query.QuerySet.exclude` calls. Everything inside a
|
||||
single :meth:`~django.db.models.query.QuerySet.filter` call is applied
|
||||
simultaneously to filter out items matching all those requirements. Successive
|
||||
:meth:`~django.db.models.query.QuerySet.filter` calls further restrict the set
|
||||
|
@ -634,7 +634,7 @@ issue the query::
|
|||
.. versionadded:: 1.3
|
||||
|
||||
For date and date/time fields, you can add or subtract a
|
||||
:class:`~datetime.timedelta` object. The following would return all entries
|
||||
:class:`~datetime.timedelta` object. The following would return all entries
|
||||
that were modified more than 3 days after they were published::
|
||||
|
||||
>>> from datetime import timedelta
|
||||
|
@ -942,7 +942,7 @@ a :class:`~django.db.models.query.QuerySet`. You can do this with the
|
|||
|
||||
You can only set non-relation fields and :class:`~django.db.models.ForeignKey`
|
||||
fields using this method. To update a non-relation field, provide the new value
|
||||
as a constant. To update :class:`~django.db.models.ForeignKey` fields, set the
|
||||
as a constant. To update :class:`~django.db.models.ForeignKey` fields, set the
|
||||
new value to be the new model instance you want to point to. For example::
|
||||
|
||||
>>> b = Blog.objects.get(pk=1)
|
||||
|
@ -969,7 +969,7 @@ statement. It is a bulk operation for direct updates. It doesn't run any
|
|||
:meth:`~django.db.models.Model.save`). If you want to save every item in a
|
||||
:class:`~django.db.models.query.QuerySet` and make sure that the
|
||||
:meth:`~django.db.models.Model.save` method is called on each instance, you
|
||||
don't need any special function to handle that. Just loop over them and call
|
||||
don't need any special function to handle that. Just loop over them and call
|
||||
:meth:`~django.db.models.Model.save`::
|
||||
|
||||
for item in my_queryset:
|
||||
|
@ -1035,7 +1035,7 @@ Example::
|
|||
|
||||
You can get and set via a foreign-key attribute. As you may expect, changes to
|
||||
the foreign key aren't saved to the database until you call
|
||||
:meth:`~django.db.models.Model.save`. Example::
|
||||
:meth:`~django.db.models.Model.save`. Example::
|
||||
|
||||
>>> e = Entry.objects.get(id=2)
|
||||
>>> e.blog = some_blog
|
||||
|
|
|
@ -1477,13 +1477,13 @@ decorate the class::
|
|||
|
||||
.. note::
|
||||
|
||||
When overriding settings make sure to also handle the cases in which your
|
||||
app's code uses a cache or similar feature that retains state even if the
|
||||
When overriding settings, make sure to handle the cases in which your app's
|
||||
code uses a cache or similar feature that retains state even if the
|
||||
setting is changed. Django provides the
|
||||
:data:`django.test.signals.setting_changed` signal to connect cleanup and
|
||||
other state-resetting callbacks to. Note that this signal isn't currently
|
||||
used by Django itself, so changing built-in settings may not yield the
|
||||
results you expect.
|
||||
:data:`django.test.signals.setting_changed` signal that lets you register
|
||||
callbacks to clean up and otherwise reset state when settings are changed.
|
||||
Note that this signal isn't currently used by Django itself, so changing
|
||||
built-in settings may not yield the results you expect.
|
||||
|
||||
Emptying the test outbox
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -508,7 +508,7 @@ class AdminViewBasicTest(TestCase):
|
|||
|
||||
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
|
||||
is English. See #13388 and #3594 for more details.
|
||||
"""
|
||||
|
@ -529,7 +529,7 @@ class AdminViewBasicTest(TestCase):
|
|||
|
||||
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.
|
||||
"""
|
||||
with self.settings(LANGUAGE_CODE='ru', USE_L10N=False):
|
||||
|
@ -2862,7 +2862,7 @@ class NeverCacheTests(TestCase):
|
|||
self.assertEqual(get_max_age(response), None)
|
||||
|
||||
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/')
|
||||
self.assertEqual(get_max_age(response), None)
|
||||
|
||||
|
@ -2896,7 +2896,7 @@ class PrePopulatedTest(TestCase):
|
|||
def test_prepopulated_maxlength_localized(self):
|
||||
"""
|
||||
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/')
|
||||
self.assertContains(response, "maxLength: 1000") # instead of 1,000
|
||||
|
@ -2909,7 +2909,7 @@ class SeleniumPrePopulatedFirefoxTests(AdminSeleniumWebDriverTestCase):
|
|||
|
||||
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.
|
||||
Refs #13068, #9264, #9983, #9784.
|
||||
"""
|
||||
|
|
Loading…
Reference in New Issue