mirror of
https://github.com/django/django.git
synced 2025-08-04 10:59:45 +00:00
Fixed many more ReST indentation errors, somehow accidentally missed from [16955]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Luke Plant
parent
5109ac3709
commit
d1e5c55258
129 changed files with 5708 additions and 5740 deletions
|
|
@ -510,23 +510,23 @@ Has one **required** argument:
|
|||
to be passed along to the storage system. The two arguments that will be
|
||||
passed are:
|
||||
|
||||
====================== ===============================================
|
||||
Argument Description
|
||||
====================== ===============================================
|
||||
``instance`` An instance of the model where the
|
||||
``FileField`` is defined. More specifically,
|
||||
this is the particular instance where the
|
||||
current file is being attached.
|
||||
====================== ===============================================
|
||||
Argument Description
|
||||
====================== ===============================================
|
||||
``instance`` An instance of the model where the
|
||||
``FileField`` is defined. More specifically,
|
||||
this is the particular instance where the
|
||||
current file is being attached.
|
||||
|
||||
In most cases, this object will not have been
|
||||
saved to the database yet, so if it uses the
|
||||
default ``AutoField``, *it might not yet have a
|
||||
value for its primary key field*.
|
||||
In most cases, this object will not have been
|
||||
saved to the database yet, so if it uses the
|
||||
default ``AutoField``, *it might not yet have a
|
||||
value for its primary key field*.
|
||||
|
||||
``filename`` The filename that was originally given to the
|
||||
file. This may or may not be taken into account
|
||||
when determining the final destination path.
|
||||
====================== ===============================================
|
||||
``filename`` The filename that was originally given to the
|
||||
file. This may or may not be taken into account
|
||||
when determining the final destination path.
|
||||
====================== ===============================================
|
||||
|
||||
Also has one optional argument:
|
||||
|
||||
|
|
@ -541,22 +541,22 @@ widget).
|
|||
Using a :class:`FileField` or an :class:`ImageField` (see below) in a model
|
||||
takes a few steps:
|
||||
|
||||
1. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as the
|
||||
full path to a directory where you'd like Django to store uploaded files.
|
||||
(For performance, these files are not stored in the database.) Define
|
||||
:setting:`MEDIA_URL` as the base public URL of that directory. Make sure
|
||||
that this directory is writable by the Web server's user account.
|
||||
1. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as the
|
||||
full path to a directory where you'd like Django to store uploaded files.
|
||||
(For performance, these files are not stored in the database.) Define
|
||||
:setting:`MEDIA_URL` as the base public URL of that directory. Make sure
|
||||
that this directory is writable by the Web server's user account.
|
||||
|
||||
2. Add the :class:`FileField` or :class:`ImageField` to your model, making
|
||||
sure to define the :attr:`~FileField.upload_to` option to tell Django
|
||||
to which subdirectory of :setting:`MEDIA_ROOT` it should upload files.
|
||||
2. Add the :class:`FileField` or :class:`ImageField` to your model, making
|
||||
sure to define the :attr:`~FileField.upload_to` option to tell Django
|
||||
to which subdirectory of :setting:`MEDIA_ROOT` it should upload files.
|
||||
|
||||
3. All that will be stored in your database is a path to the file
|
||||
(relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
|
||||
convenience :attr:`~django.core.files.File.url` function provided by
|
||||
Django. For example, if your :class:`ImageField` is called ``mug_shot``,
|
||||
you can get the absolute path to your image in a template with
|
||||
``{{ object.mug_shot.url }}``.
|
||||
3. All that will be stored in your database is a path to the file
|
||||
(relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
|
||||
convenience :attr:`~django.core.files.File.url` function provided by
|
||||
Django. For example, if your :class:`ImageField` is called ``mug_shot``,
|
||||
you can get the absolute path to your image in a template with
|
||||
``{{ object.mug_shot.url }}``.
|
||||
|
||||
For example, say your :setting:`MEDIA_ROOT` is set to ``'/home/media'``, and
|
||||
:attr:`~FileField.upload_to` is set to ``'photos/%Y/%m/%d'``. The ``'%Y/%m/%d'``
|
||||
|
|
|
|||
|
|
@ -34,9 +34,9 @@ Validating objects
|
|||
|
||||
There are three steps involved in validating a model:
|
||||
|
||||
1. Validate the model fields
|
||||
2. Validate the model as a whole
|
||||
3. Validate the field uniqueness
|
||||
1. Validate the model fields
|
||||
2. Validate the model as a whole
|
||||
3. Validate the field uniqueness
|
||||
|
||||
All three steps are performed when you call a model's
|
||||
:meth:`~Model.full_clean()` method.
|
||||
|
|
@ -211,43 +211,43 @@ What happens when you save?
|
|||
|
||||
When you save an object, Django performs the following steps:
|
||||
|
||||
1. **Emit a pre-save signal.** The :doc:`signal </ref/signals>`
|
||||
:attr:`django.db.models.signals.pre_save` is sent, allowing any
|
||||
functions listening for that signal to take some customized
|
||||
action.
|
||||
1. **Emit a pre-save signal.** The :doc:`signal </ref/signals>`
|
||||
:attr:`django.db.models.signals.pre_save` is sent, allowing any
|
||||
functions listening for that signal to take some customized
|
||||
action.
|
||||
|
||||
2. **Pre-process the data.** Each field on the object is asked to
|
||||
perform any automated data modification that the field may need
|
||||
to perform.
|
||||
2. **Pre-process the data.** Each field on the object is asked to
|
||||
perform any automated data modification that the field may need
|
||||
to perform.
|
||||
|
||||
Most fields do *no* pre-processing — the field data is kept as-is.
|
||||
Pre-processing is only used on fields that have special behavior. For
|
||||
example, if your model has a :class:`~django.db.models.DateField` with
|
||||
``auto_now=True``, the pre-save phase will alter the data in the object
|
||||
to ensure that the date field contains the current date stamp. (Our
|
||||
documentation doesn't yet include a list of all the fields with this
|
||||
"special behavior.")
|
||||
Most fields do *no* pre-processing — the field data is kept as-is.
|
||||
Pre-processing is only used on fields that have special behavior. For
|
||||
example, if your model has a :class:`~django.db.models.DateField` with
|
||||
``auto_now=True``, the pre-save phase will alter the data in the object
|
||||
to ensure that the date field contains the current date stamp. (Our
|
||||
documentation doesn't yet include a list of all the fields with this
|
||||
"special behavior.")
|
||||
|
||||
3. **Prepare the data for the database.** Each field is asked to provide
|
||||
its current value in a data type that can be written to the database.
|
||||
3. **Prepare the data for the database.** Each field is asked to provide
|
||||
its current value in a data type that can be written to the database.
|
||||
|
||||
Most fields require *no* data preparation. Simple data types, such as
|
||||
integers and strings, are 'ready to write' as a Python object. However,
|
||||
more complex data types often require some modification.
|
||||
Most fields require *no* data preparation. Simple data types, such as
|
||||
integers and strings, are 'ready to write' as a Python object. However,
|
||||
more complex data types often require some modification.
|
||||
|
||||
For example, :class:`~django.db.models.DateField` fields use a Python
|
||||
``datetime`` object to store data. Databases don't store ``datetime``
|
||||
objects, so the field value must be converted into an ISO-compliant date
|
||||
string for insertion into the database.
|
||||
For example, :class:`~django.db.models.DateField` fields use a Python
|
||||
``datetime`` object to store data. Databases don't store ``datetime``
|
||||
objects, so the field value must be converted into an ISO-compliant date
|
||||
string for insertion into the database.
|
||||
|
||||
4. **Insert the data into the database.** The pre-processed, prepared
|
||||
data is then composed into an SQL statement for insertion into the
|
||||
database.
|
||||
4. **Insert the data into the database.** The pre-processed, prepared
|
||||
data is then composed into an SQL statement for insertion into the
|
||||
database.
|
||||
|
||||
5. **Emit a post-save signal.** The signal
|
||||
:attr:`django.db.models.signals.post_save` is sent, allowing
|
||||
any functions listening for that signal to take some customized
|
||||
action.
|
||||
5. **Emit a post-save signal.** The signal
|
||||
:attr:`django.db.models.signals.post_save` is sent, allowing
|
||||
any functions listening for that signal to take some customized
|
||||
action.
|
||||
|
||||
How Django knows to UPDATE vs. INSERT
|
||||
-------------------------------------
|
||||
|
|
@ -257,14 +257,14 @@ for creating and changing objects. Django abstracts the need to use ``INSERT``
|
|||
or ``UPDATE`` SQL statements. Specifically, when you call ``save()``, Django
|
||||
follows this algorithm:
|
||||
|
||||
* If the object's primary key attribute is set to a value that evaluates to
|
||||
``True`` (i.e., a value other than ``None`` or the empty string), Django
|
||||
executes a ``SELECT`` query to determine whether a record with the given
|
||||
primary key already exists.
|
||||
* If the record with the given primary key does already exist, Django
|
||||
executes an ``UPDATE`` query.
|
||||
* If the object's primary key attribute is *not* set, or if it's set but a
|
||||
record doesn't exist, Django executes an ``INSERT``.
|
||||
* If the object's primary key attribute is set to a value that evaluates to
|
||||
``True`` (i.e., a value other than ``None`` or the empty string), Django
|
||||
executes a ``SELECT`` query to determine whether a record with the given
|
||||
primary key already exists.
|
||||
* If the record with the given primary key does already exist, Django
|
||||
executes an ``UPDATE`` query.
|
||||
* If the object's primary key attribute is *not* set, or if it's set but a
|
||||
record doesn't exist, Django executes an ``INSERT``.
|
||||
|
||||
The one gotcha here is that you should be careful not to specify a primary-key
|
||||
value explicitly when saving new objects, if you cannot guarantee the
|
||||
|
|
|
|||
|
|
@ -107,21 +107,21 @@ Django quotes column and table names behind the scenes.
|
|||
the *only* difference when ``managed=False``. All other aspects of
|
||||
model handling are exactly the same as normal. This includes
|
||||
|
||||
1. Adding an automatic primary key field to the model if you don't
|
||||
declare it. To avoid confusion for later code readers, it's
|
||||
recommended to specify all the columns from the database table you
|
||||
are modeling when using unmanaged models.
|
||||
1. Adding an automatic primary key field to the model if you don't
|
||||
declare it. To avoid confusion for later code readers, it's
|
||||
recommended to specify all the columns from the database table you
|
||||
are modeling when using unmanaged models.
|
||||
|
||||
2. If a model with ``managed=False`` contains a
|
||||
:class:`~django.db.models.ManyToManyField` that points to another
|
||||
unmanaged model, then the intermediate table for the many-to-many
|
||||
join will also not be created. However, the intermediary table
|
||||
between one managed and one unmanaged model *will* be created.
|
||||
2. If a model with ``managed=False`` contains a
|
||||
:class:`~django.db.models.ManyToManyField` that points to another
|
||||
unmanaged model, then the intermediate table for the many-to-many
|
||||
join will also not be created. However, the intermediary table
|
||||
between one managed and one unmanaged model *will* be created.
|
||||
|
||||
If you need to change this default behavior, create the intermediary
|
||||
table as an explicit model (with ``managed`` set as needed) and use
|
||||
the :attr:`ManyToManyField.through` attribute to make the relation
|
||||
use your custom model.
|
||||
If you need to change this default behavior, create the intermediary
|
||||
table as an explicit model (with ``managed`` set as needed) and use
|
||||
the :attr:`ManyToManyField.through` attribute to make the relation
|
||||
use your custom model.
|
||||
|
||||
For tests involving models with ``managed=False``, it's up to you to ensure
|
||||
the correct tables are created as part of the test setup.
|
||||
|
|
|
|||
|
|
@ -9,28 +9,28 @@ Related objects reference
|
|||
A "related manager" is a manager used in a one-to-many or many-to-many
|
||||
related context. This happens in two cases:
|
||||
|
||||
* The "other side" of a :class:`~django.db.models.ForeignKey` relation.
|
||||
That is::
|
||||
* The "other side" of a :class:`~django.db.models.ForeignKey` relation.
|
||||
That is::
|
||||
|
||||
class Reporter(models.Model):
|
||||
...
|
||||
class Reporter(models.Model):
|
||||
...
|
||||
|
||||
class Article(models.Model):
|
||||
reporter = models.ForeignKey(Reporter)
|
||||
class Article(models.Model):
|
||||
reporter = models.ForeignKey(Reporter)
|
||||
|
||||
In the above example, the methods below will be available on
|
||||
the manager ``reporter.article_set``.
|
||||
In the above example, the methods below will be available on
|
||||
the manager ``reporter.article_set``.
|
||||
|
||||
* Both sides of a :class:`~django.db.models.ManyToManyField` relation::
|
||||
* Both sides of a :class:`~django.db.models.ManyToManyField` relation::
|
||||
|
||||
class Topping(models.Model):
|
||||
...
|
||||
class Topping(models.Model):
|
||||
...
|
||||
|
||||
class Pizza(models.Model):
|
||||
toppings = models.ManyToManyField(Topping)
|
||||
class Pizza(models.Model):
|
||||
toppings = models.ManyToManyField(Topping)
|
||||
|
||||
In this example, the methods below will be available both on
|
||||
``topping.pizza_set`` and on ``pizza.toppings``.
|
||||
In this example, the methods below will be available both on
|
||||
``topping.pizza_set`` and on ``pizza.toppings``.
|
||||
|
||||
These related managers have some extra methods:
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue