mirror of
https://github.com/django/django.git
synced 2025-08-31 07:47:37 +00:00
Used auto-numbered lists in documentation.
This commit is contained in:
parent
cf915cb513
commit
9b15ff08ba
36 changed files with 169 additions and 173 deletions
|
@ -697,17 +697,17 @@ The default form widget for this field is a
|
|||
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
|
||||
#. 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, defining
|
||||
#. Add the :class:`FileField` or :class:`ImageField` to your model, defining
|
||||
the :attr:`~FileField.upload_to` option to specify a subdirectory of
|
||||
:setting:`MEDIA_ROOT` to use for uploaded files.
|
||||
|
||||
3. All that will be stored in your database is a path to the file
|
||||
#. 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.db.models.fields.files.FieldFile.url` attribute
|
||||
provided by Django. For example, if your :class:`ImageField` is called
|
||||
|
|
|
@ -32,7 +32,7 @@ that, you need to :meth:`~Model.save()`.
|
|||
signature as any change may prevent the model instance from being saved.
|
||||
Rather than overriding ``__init__``, try using one of these approaches:
|
||||
|
||||
1. Add a classmethod on the model class::
|
||||
#. Add a classmethod on the model class::
|
||||
|
||||
from django.db import models
|
||||
|
||||
|
@ -47,7 +47,7 @@ that, you need to :meth:`~Model.save()`.
|
|||
|
||||
book = Book.create("Pride and Prejudice")
|
||||
|
||||
2. Add a method on a custom manager (usually preferred)::
|
||||
#. Add a method on a custom manager (usually preferred)::
|
||||
|
||||
class BookManager(models.Manager):
|
||||
def create_book(self, title):
|
||||
|
@ -135,9 +135,9 @@ If you need to reload a model's values from the database, you can use the
|
|||
``refresh_from_db()`` method. When this method is called without arguments the
|
||||
following is done:
|
||||
|
||||
1. All non-deferred fields of the model are updated to the values currently
|
||||
#. All non-deferred fields of the model are updated to the values currently
|
||||
present in the database.
|
||||
2. Any cached relations are cleared from the reloaded instance.
|
||||
#. Any cached relations are cleared from the reloaded instance.
|
||||
|
||||
Only fields of the model are reloaded from the database. Other
|
||||
database-dependent values such as annotations aren't reloaded. Any
|
||||
|
|
|
@ -163,12 +163,12 @@ 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
|
||||
#. 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
|
||||
#. 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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue