test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
django/docs/ref/models/fields.txt

948 lines
33 KiB
Plaintext
Raw Blame History

.. _ref-models-fields:
=====================
Model field reference
=====================
.. module:: django.db.models.fields
:synopsis: Built-in field types.
This document contains all the gory details about all the `field options`_ and
`field types`_ Django's got to offer.
.. seealso::
If the built-in fields don't do the trick, you can easily :ref:`write your
own custom model fields <howto-custom-model-fields>`.
.. note::
Technically, these models are defined in :mod:`django.db.models.fields`, but
for convenience they're imported into :mod:`django.db.models`; the standard
convention is to use ``from django.db import models`` and refer to fields as
``models.<Foo>Field``.
.. _common-model-field-options:
Field options
=============
The following arguments are available to all field types. All are optional.
``null``
--------
.. attribute:: Field.null
If ``True``, Django will store empty values as ``NULL`` in the database. Default
is ``False``.
Note that empty string values will always get stored as empty strings, not as
``NULL``. Only use ``null=True`` for non-string fields such as integers,
booleans and dates. For both types of fields, you will also need to set
``blank=True`` if you wish to permit empty values in forms, as the
:attr:`~Field.null` parameter only affects database storage (see
:attr:`~Field.blank`).
Avoid using :attr:`~Field.null` on string-based fields such as
:class:`CharField` and :class:`TextField` unless you have an excellent reason.
If a string-based field has ``null=True``, that means it has two possible values
for "no data": ``NULL``, and the empty string. In most cases, it's redundant to
have two possible values for "no data;" Django convention is to use the empty
string, not ``NULL``.
.. note::
When using the Oracle database backend, the ``null=True`` option will be
coerced for string-based fields that have the empty string as a possible
value, and the value ``NULL`` will be stored to denote the empty string.
``blank``
---------
.. attribute:: Field.blank
If ``True``, the field is allowed to be blank. Default is ``False``.
Note that this is different than :attr:`~Field.null`. :attr:`~Field.null` is
purely database-related, whereas :attr:`~Field.blank` is validation-related. If
a field has ``blank=True``, validation on Django's admin site will allow entry
of an empty value. If a field has ``blank=False``, the field will be required.
``choices``
-----------
.. attribute:: Field.choices
An iterable (e.g., a list or tuple) of 2-tuples to use as choices for this
field.
If this is given, Django's admin will use a select box instead of the standard
text field and will limit choices to the choices given.
A choices list looks like this::
YEAR_IN_SCHOOL_CHOICES = (
('FR', 'Freshman'),
('SO', 'Sophomore'),
('JR', 'Junior'),
('SR', 'Senior'),
('GR', 'Graduate'),
)
The first element in each tuple is the actual value to be stored. The second
element is the human-readable name for the option.
The choices list can be defined either as part of your model class::
class Foo(models.Model):
GENDER_CHOICES = (
('M', 'Male'),
('F', 'Female'),
)
gender = models.CharField(max_length=1, choices=GENDER_CHOICES)
or outside your model class altogether::
GENDER_CHOICES = (
('M', 'Male'),
('F', 'Female'),
)
class Foo(models.Model):
gender = models.CharField(max_length=1, choices=GENDER_CHOICES)
You can also collect your available choices into named groups that can
be used for organizational purposes::
MEDIA_CHOICES = (
('Audio', (
('vinyl', 'Vinyl'),
('cd', 'CD'),
)
),
('Video', (
('vhs', 'VHS Tape'),
('dvd', 'DVD'),
)
),
('unknown', 'Unknown'),
)
The first element in each tuple is the name to apply to the group. The
second element is an iterable of 2-tuples, with each 2-tuple containing
a value and a human-readable name for an option. Grouped options may be
combined with ungrouped options within a single list (such as the
`unknown` option in this example).
For each model field that has :attr:`~Field.choices` set, Django will add a
method to retrieve the human-readable name for the field's current value. See
:meth:`~django.db.models.Model.get_FOO_display` in the database API
documentation.
Finally, note that choices can be any iterable object -- not necessarily a list
or tuple. This lets you construct choices dynamically. But if you find yourself
hacking :attr:`~Field.choices` to be dynamic, you're probably better off using a
proper database table with a :class:`ForeignKey`. :attr:`~Field.choices` is
meant for static data that doesn't change much, if ever.
``db_column``
-------------
.. attribute:: Field.db_column
The name of the database column to use for this field. If this isn't given,
Django will use the field's name.
If your database column name is an SQL reserved word, or contains
characters that aren't allowed in Python variable names -- notably, the
hyphen -- that's OK. Django quotes column and table names behind the
scenes.
``db_index``
------------
.. attribute:: Field.db_index
If ``True``, djadmin:`django-admin.py sqlindexes <sqlindexes>` will output a
``CREATE INDEX`` statement for this field.
``db_tablespace``
-----------------
.. attribute:: Field.db_tablespace
.. versionadded:: 1.0
The name of the database tablespace to use for this field's index, if this field
is indexed. The default is the project's :setting:`DEFAULT_INDEX_TABLESPACE`
setting, if set, or the :attr:`~Field.db_tablespace` of the model, if any. If
the backend doesn't support tablespaces, this option is ignored.
``default``
-----------
.. attribute:: Field.default
The default value for the field. This can be a value or a callable object. If
callable it will be called every time a new object is created.
``editable``
------------
.. attribute:: Field.editable
If ``False``, the field will not be editable in the admin or via forms
automatically generated from the model class. Default is ``True``.
``help_text``
-------------
.. attribute:: Field.help_text
Extra "help" text to be displayed under the field on the object's admin form.
It's useful for documentation even if your object doesn't have an admin form.
Note that this value is *not* HTML-escaped when it's displayed in the admin
interface. This lets you include HTML in :attr:`~Field.help_text` if you so
desire. For example::
help_text="Please use the following format: <em>YYYY-MM-DD</em>."
Alternatively you can use plain text and
``django.utils.html.escape()`` to escape any HTML special characters.
``primary_key``
---------------
.. attribute:: Field.primary_key
If ``True``, this field is the primary key for the model.
If you don't specify ``primary_key=True`` for any fields in your model, Django
will automatically add an :class:`IntegerField` to hold the primary key, so you
don't need to set ``primary_key=True`` on any of your fields unless you want to
override the default primary-key behavior. For more, see
:ref:`automatic-primary-key-fields`.
``primary_key=True`` implies :attr:`null=False <Field.null>` and :attr:`unique=True <Field.unique>`.
Only one primary key is allowed on an object.
``unique``
----------
.. attribute:: Field.unique
If ``True``, this field must be unique throughout the table.
This is enforced at the database level and at the Django admin-form level. If
you try to save a model with a duplicate value in a :attr:`~Field.unique`
field, a :exc:`django.db.IntegrityError` will be raised by the model's
:meth:`~django.db.models.Model.save` method.
This option is valid on all field types except :class:`ManyToManyField`.
``unique_for_date``
-------------------
.. attribute:: Field.unique_for_date
Set this to the name of a :class:`DateField` or :class:`DateTimeField` to
require that this field be unique for the value of the date field.
For example, if you have a field ``title`` that has
``unique_for_date="pub_date"``, then Django wouldn't allow the entry of two
records with the same ``title`` and ``pub_date``.
This is enforced at the Django admin-form level but not at the database level.
``unique_for_month``
--------------------
.. attribute:: Field.unique_for_month
Like :attr:`~Field.unique_for_date`, but requires the field to be unique with
respect to the month.
``unique_for_year``
-------------------
.. attribute:: Field.unique_for_year
Like :attr:`~Field.unique_for_date` and :attr:`~Field.unique_for_month`.
``verbose_name``
-------------------
.. attribute:: Field.verbose_name
A human-readable name for the field. If the verbose name isn't given, Django
will automatically create it using the field's attribute name, converting
underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
.. _model-field-types:
Field types
===========
.. currentmodule:: django.db.models
``AutoField``
-------------
.. class:: AutoField(**options)
An :class:`IntegerField` that automatically increments
according to available IDs. You usually won't need to use this directly; a
primary key field will automatically be added to your model if you don't specify
otherwise. See :ref:`automatic-primary-key-fields`.
``BooleanField``
----------------
.. class:: BooleanField(**options)
A true/false field.
The admin represents this as a checkbox.
.. admonition:: MySQL users..
A boolean field in MySQL is stored as a ``TINYINT`` column with a value of
either 0 or 1 (most databases have a proper ``BOOLEAN`` type instead). So,
for MySQL, only, when a ``BooleanField`` is retrieved from the database
and stored on a model attribute, it will have the values 1 or 0, rather
than ``True`` or ``False``. Normally, this shouldn't be a problem, since
Python guarantees that ``1 == True`` and ``0 == False`` are both true.
Just be careful if you're writing something like ``obj is True`` when
``obj`` is a value from a boolean attribute on a model. If that model was
constructed using the ``mysql`` backend, the "``is``" test will fail.
Prefer an equality test (using "``==``") in cases like this.
``CharField``
-------------
.. class:: CharField(max_length=None, [**options])
A string field, for small- to large-sized strings.
For large amounts of text, use :class:`~django.db.models.TextField`.
The admin represents this as an ``<input type="text">`` (a single-line input).
:class:`CharField` has one extra required argument:
.. attribute:: CharField.max_length
The maximum length (in characters) of the field. The max_length is enforced
at the database level and in Django's validation.
.. note::
If you are writing an application that must be portable to multiple
database backends, you should be aware that there are restrictions on
``max_length`` for some backends. Refer to the :ref:`database backend
notes <ref-databases>` for details.
.. admonition:: MySQL users
If you are using this field with MySQLdb 1.2.2 and the ``utf8_bin``
collation (which is *not* the default), there are some issues to be aware
of. Refer to the :ref:`MySQL database notes <mysql-collation>` for
details.
``CommaSeparatedIntegerField``
------------------------------
.. class:: CommaSeparatedIntegerField(max_length=None, [**options])
A field of integers separated by commas. As in :class:`CharField`, the
:attr:`~CharField.max_length` argument is required and the note about database
portability mentioned there should be heeded.
``DateField``
-------------
.. class:: DateField([auto_now=False, auto_now_add=False, **options])
A date field. Has a few extra optional arguments:
.. attribute:: DateField.auto_now
Automatically set the field to now every time the object is saved. Useful
for "last-modified" timestamps. Note that the current date is *always* used;
it's not just a default value that you can override.
.. attribute:: DateField.auto_now_add
Automatically set the field to now when the object is first created. Useful
for creation of timestamps. Note that the current date is *always* used;
it's not just a default value that you can override.
The admin represents this as an ``<input type="text">`` with a JavaScript
calendar, and a shortcut for "Today". The JavaScript calendar will always start
the week on a Sunday.
``DateTimeField``
-----------------
.. class:: DateTimeField([auto_now=False, auto_now_add=False, **options])
A date and time field. Takes the same extra options as :class:`DateField`.
The admin represents this as two ``<input type="text">`` fields, with JavaScript
shortcuts.
``DecimalField``
----------------
.. versionadded:: 1.0
.. class:: DecimalField(max_digits=None, decimal_places=None, [**options])
A fixed-precision decimal number, represented in Python by a
:class:`~decimal.Decimal` instance. Has two **required** arguments:
.. attribute:: DecimalField.max_digits
The maximum number of digits allowed in the number
.. attribute:: DecimalField.decimal_places
The number of decimal places to store with the number
For example, to store numbers up to 999 with a resolution of 2 decimal places,
you'd use::
models.DecimalField(..., max_digits=5, decimal_places=2)
And to store numbers up to approximately one billion with a resolution of 10
decimal places::
models.DecimalField(..., max_digits=19, decimal_places=10)
The admin represents this as an ``<input type="text">`` (a single-line input).
``EmailField``
--------------
.. class:: EmailField([max_length=75, **options])
A :class:`CharField` that checks that the value is a valid e-mail address.
``FileField``
-------------
.. class:: FileField(upload_to=None, [max_length=100, **options])
A file-upload field. Has one **required** argument:
.. attribute:: FileField.upload_to
A local filesystem path that will be appended to your :setting:`MEDIA_ROOT`
setting to determine the value of the :attr:`~django.core.files.File.url`
attribute.
This path may contain `strftime formatting`_, which will be replaced by the
date/time of the file upload (so that uploaded files don't fill up the given
directory).
.. versionchanged:: 1.0
This may also be a callable, such as a function, which will be called to
obtain the upload path, including the filename. This callable must be able
to accept two arguments, and return a Unix-style path (with forward slashes)
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.
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.
====================== ===============================================
Also has one optional argument:
.. attribute:: FileField.storage
.. versionadded:: 1.0
Optional. A storage object, which handles the storage and retrieval of your
files. See :ref:`topics-files` for details on how to provide this object.
The admin represents this field as an ``<input type="file">`` (a file-upload
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.
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 URL 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'``
part of :attr:`~FileField.upload_to` is `strftime formatting`_; ``'%Y'`` is the
four-digit year, ``'%m'`` is the two-digit month and ``'%d'`` is the two-digit
day. If you upload a file on Jan. 15, 2007, it will be saved in the directory
``/home/media/photos/2007/01/15``.
If you want to retrieve the upload file's on-disk filename, or a URL that refers
to that file, or the file's size, you can use the
:attr:`~django.core.files.File.name`, :attr:`~django.core.files.File.url`
and :attr:`~django.core.files.File.size` attributes; see :ref:`topics-files`.
Note that whenever you deal with uploaded files, you should pay close attention
to where you're uploading them and what type of files they are, to avoid
security holes. *Validate all uploaded files* so that you're sure the files are
what you think they are. For example, if you blindly let somebody upload files,
without validation, to a directory that's within your Web server's document
root, then somebody could upload a CGI or PHP script and execute that script by
visiting its URL on your site. Don't allow that.
.. versionadded:: 1.0
The ``max_length`` argument was added in this version.
By default, :class:`FileField` instances are
created as ``varchar(100)`` columns in your database. As with other fields, you
can change the maximum length using the :attr:`~CharField.max_length` argument.
.. _`strftime formatting`: http://docs.python.org/lib/module-time.html#l2h-1941
``FilePathField``
-----------------
.. class:: FilePathField(path=None, [match=None, recursive=False, max_length=100, **options])
A :class:`CharField` whose choices are limited to the filenames in a certain
directory on the filesystem. Has three special arguments, of which the first is
**required**:
.. attribute:: FilePathField.path
Required. The absolute filesystem path to a directory from which this
:class:`FilePathField` should get its choices. Example: ``"/home/images"``.
.. attribute:: FilePathField.match
Optional. A regular expression, as a string, that :class:`FilePathField`
will use to filter filenames. Note that the regex will be applied to the
base filename, not the full path. Example: ``"foo.*\.txt$"``, which will
match a file called ``foo23.txt`` but not ``bar.txt`` or ``foo23.gif``.
.. attribute:: FilePathField.recursive
Optional. Either ``True`` or ``False``. Default is ``False``. Specifies
whether all subdirectories of :attr:`~FilePathField.path` should be included
Of course, these arguments can be used together.
The one potential gotcha is that :attr:`~FilePathField.match` applies to the
base filename, not the full path. So, this example::
FilePathField(path="/home/images", match="foo.*", recursive=True)
...will match ``/home/images/foo.gif`` but not ``/home/images/foo/bar.gif``
because the :attr:`~FilePathField.match` applies to the base filename
(``foo.gif`` and ``bar.gif``).
.. versionadded:: 1.0
The ``max_length`` argument was added in this version.
By default, :class:`FilePathField` instances are
created as ``varchar(100)`` columns in your database. As with other fields, you
can change the maximum length using the :attr:`~CharField.max_length` argument.
``FloatField``
--------------
.. class:: FloatField([**options])
.. versionchanged:: 1.0
A floating-point number represented in Python by a ``float`` instance.
The admin represents this as an ``<input type="text">`` (a single-line input).
``ImageField``
--------------
.. class:: ImageField(upload_to=None, [height_field=None, width_field=None, max_length=100, **options])
Like :class:`FileField`, but validates that the uploaded object is a valid
image. Has two extra optional arguments:
.. attribute:: ImageField.height_field
Name of a model field which will be auto-populated with the height of the
image each time the model instance is saved.
.. attribute:: ImageField.width_field
Name of a model field which will be auto-populated with the width of the
image each time the model instance is saved.
In addition to the special attributes that are available for :class:`FileField`,
an :class:`ImageField` also has ``File.height`` and ``File.width`` attributes.
See :ref:`topics-files`.
Requires the `Python Imaging Library`_.
.. _Python Imaging Library: http://www.pythonware.com/products/pil/
.. versionadded:: 1.0
The ``max_length`` argument was added in this version.
By default, :class:`ImageField` instances are
created as ``varchar(100)`` columns in your database. As with other fields, you
can change the maximum length using the :attr:`~CharField.max_length` argument.
``IntegerField``
----------------
.. class:: IntegerField([**options])
An integer. The admin represents this as an ``<input type="text">`` (a
single-line input).
``IPAddressField``
------------------
.. class:: IPAddressField([**options])
An IP address, in string format (e.g. "192.0.2.30"). The admin represents this
as an ``<input type="text">`` (a single-line input).
``NullBooleanField``
--------------------
.. class:: NullBooleanField([**options])
Like a :class:`BooleanField`, but allows ``NULL`` as one of the options. Use
this instead of a :class:`BooleanField` with ``null=True``. The admin represents
this as a ``<select>`` box with "Unknown", "Yes" and "No" choices.
``PositiveIntegerField``
------------------------
.. class:: PositiveIntegerField([**options])
Like an :class:`IntegerField`, but must be positive.
``PositiveSmallIntegerField``
-----------------------------
.. class:: PositiveSmallIntegerField([**options])
Like a :class:`PositiveIntegerField`, but only allows values under a certain
(database-dependent) point.
``SlugField``
-------------
.. class:: SlugField([max_length=50, **options])
:term:`Slug` is a newspaper term. A slug is a short label for something,
containing only letters, numbers, underscores or hyphens. They're generally used
in URLs.
Like a CharField, you can specify :attr:`~CharField.max_length` (read the note
about database portability and :attr:`~CharField.max_length` in that section,
too). If :attr:`~CharField.max_length` is not specified, Django will use a
default length of 50.
Implies setting :attr:`Field.db_index` to ``True``.
``SmallIntegerField``
---------------------
.. class:: SmallIntegerField([**options])
Like an :class:`IntegerField`, but only allows values under a certain
(database-dependent) point.
``TextField``
-------------
.. class:: TextField([**options])
A large text field. The admin represents this as a ``<textarea>`` (a multi-line
input).
.. admonition:: MySQL users
If you are using this field with MySQLdb 1.2.1p2 and the ``utf8_bin``
collation (which is *not* the default), there are some issues to be aware
of. Refer to the :ref:`MySQL database notes <mysql-collation>` for
details.
``TimeField``
-------------
.. class:: TimeField([auto_now=False, auto_now_add=False, **options])
A time. Accepts the same auto-population options as :class:`DateField` and
:class:`DateTimeField`. The admin represents this as an ``<input type="text">``
with some JavaScript shortcuts.
``URLField``
------------
.. class:: URLField([verify_exists=True, max_length=200, **options])
A :class:`CharField` for a URL. Has one extra optional argument:
.. attribute:: URLField.verify_exists
If ``True`` (the default), the URL given will be checked for existence
(i.e., the URL actually loads and doesn't give a 404 response).
The admin represents this as an ``<input type="text">`` (a single-line input).
Like all ::class:`CharField` subclasses, :class:`URLField` takes the optional
:attr:`~CharField.max_length`argument. If you don't specify
:attr:`~CharField.max_length`, a default of 200 is used.
``XMLField``
------------
.. class:: XMLField(schema_path=None, [**options])
A :class:`TextField` that checks that the value is valid XML that matches a
given schema. Takes one required argument:
.. attribute:: schema_path
The filesystem path to a RelaxNG_ schema against which to validate the
field.
.. _RelaxNG: http://www.relaxng.org/
Relationship fields
===================
.. module:: django.db.models.fields.related
:synopsis: Related field types
.. currentmodule:: django.db.models
Django also defines a set of fields that represent relations.
.. _ref-foreignkey:
``ForeignKey``
--------------
.. class:: ForeignKey(othermodel, [**options])
A many-to-one relationship. Requires a positional argument: the class to which
the model is related.
.. _recursive-relationships:
To create a recursive relationship -- an object that has a many-to-one
relationship with itself -- use ``models.ForeignKey('self')``.
.. _lazy-relationships:
If you need to create a relationship on a model that has not yet been defined,
you can use the name of the model, rather than the model object itself::
class Car(models.Model):
manufacturer = models.ForeignKey('Manufacturer')
# ...
class Manufacturer(models.Model):
# ...
Note, however, that this only refers to models in the same ``models.py`` file --
you cannot use a string to reference a model defined in another application or
imported from elsewhere.
.. versionchanged:: 1.0
Refering models in other applications must include the application label.
To refer to models defined in another
application, you must instead explicitly specify the application label. For
example, if the ``Manufacturer`` model above is defined in another application
called ``production``, you'd need to use::
class Car(models.Model):
manufacturer = models.ForeignKey('production.Manufacturer')
Behind the scenes, Django appends ``"_id"`` to the field name to create its
database column name. In the above example, the database table for the ``Car``
model will have a ``manufacturer_id`` column. (You can change this explicitly by
specifying :attr:`~Field.db_column`) However, your code should never have to
deal with the database column name, unless you write custom SQL. You'll always
deal with the field names of your model object.
.. _foreign-key-arguments:
:class:`ForeignKey` accepts an extra set of arguments -- all optional -- that
define the details of how the relation works.
.. attribute:: ForeignKey.limit_choices_to
A dictionary of lookup arguments and values (see :ref:`topics-db-queries`)
that limit the available admin choices for this object. Use this with
functions from the Python ``datetime`` module to limit choices of objects by
date. For example::
limit_choices_to = {'pub_date__lte': datetime.now}
only allows the choice of related objects with a ``pub_date`` before the
current date/time to be chosen.
Instead of a dictionary this can also be a :class:`~django.db.models.Q`
object (an object with a :meth:`get_sql` method) for more complex queries.
``limit_choices_to`` has no effect on the inline FormSets that are created
to display related objects in the admin.
.. attribute:: ForeignKey.related_name
The name to use for the relation from the related object back to this one.
See the :ref:`related objects documentation <backwards-related-objects>` for
a full explanation and example. Note that you must set this value
when defining relations on :ref:`abstract models
<abstract-base-classes>`; and when you do so
:ref:`some special syntax <abstract-related-name>` is available.
.. attribute:: ForeignKey.to_field
The field on the related object that the relation is to. By default, Django
uses the primary key of the related object.
.. _ref-manytomany:
``ManyToManyField``
-------------------
.. class:: ManyToManyField(othermodel, [**options])
A many-to-many relationship. Requires a positional argument: the class to which
the model is related. This works exactly the same as it does for
:class:`ForeignKey`, including all the options regarding :ref:`recursive
<recursive-relationships>` and :ref:`lazy <lazy-relationships>` relationships.
Behind the scenes, Django creates an intermediary join table to represent the
many-to-many relationship. By default, this table name is generated using the
names of the two tables being joined. Since some databases don't support table
names above a certain length (often 32 characters), these table names will be
automatically truncated to 32 characters and a uniqueness hash will be used.
This means you might see table names like ``author_books_9cdf4``; this is
perfectly normal. You can manually provide the name of the join table using
the :attr:`~ManyToManyField.db_table` option.
.. _manytomany-arguments:
:class:`ManyToManyField` accepts an extra set of arguments -- all optional --
that control how the relationship functions.
.. attribute:: ManyToManyField.related_name
Same as :attr:`ForeignKey.related_name`.
.. attribute:: ManyToManyFields.limit_choices_to
Same as :attr:`ForeignKey.limit_choices_to`.
``limit_choices_to`` has no effect when used on a ``ManyToManyField`` with
an intermediate table.
.. attribute:: ManyToManyFields.symmetrical
Only used in the definition of ManyToManyFields on self. Consider the
following model::
class Person(models.Model):
friends = models.ManyToManyField("self")
When Django processes this model, it identifies that it has a
:class:`ManyToManyField` on itself, and as a result, it doesn't add a
``person_set`` attribute to the ``Person`` class. Instead, the
:class:`ManyToManyField` is assumed to be symmetrical -- that is, if I am
your friend, then you are my friend.
If you do not want symmetry in many-to-many relationships with ``self``, set
:attr:`~ManyToManyField.symmetrical` to ``False``. This will force Django to
add the descriptor for the reverse relationship, allowing
:class:`ManyToManyField` relationships to be non-symmetrical.
.. attribute:: ManyToManyFields.through
Django will automatically generate a table to manage many-to-many
relationships. However, if you want to manually specify the intermediary
table, you can use the :attr:`~ManyToManyField.through` option to specify
the Django model that represents the intermediate table that you want to
use.
The most common use for this option is when you want to associate
:ref:`extra data with a many-to-many relationship <intermediary-manytomany>`.
.. attribute:: ManyToManyField.db_table
The name of the table to create for storing the many-to-many data. If this
is not provided, Django will assume a default name based upon the names of
the two tables being joined.
.. _ref-onetoone:
``OneToOneField``
-----------------
.. class:: OneToOneField(othermodel, [parent_link=False, **options])
A one-to-one relationship. Conceptually, this is similar to a
:class:`ForeignKey` with :attr:`unique=True <Field.unique>`, but the
"reverse" side of the relation will directly return a single object.
This is most useful as the primary key of a model which "extends"
another model in some way; :ref:`multi-table-inheritance` is
implemented by adding an implicit one-to-one relation from the child
model to the parent model, for example.
One positional argument is required: the class to which the model will be
related. This works exactly the same as it does for :class:`ForeignKey`,
including all the options regarding :ref:`recursive <recursive-relationships>`
and :ref:`lazy <lazy-relationships>` relationships.
.. _onetoone-arguments:
Additionally, ``OneToOneField`` accepts all of the extra arguments
accepted by :class:`ForeignKey`, plus one extra argument:
.. attribute:: OneToOneField.parent_link
When ``True`` and used in a model which inherits from another
(concrete) model, indicates that this field should be used as the
link back to the parent class, rather than the extra
``OneToOneField`` which would normally be implicitly created by
subclassing.
Reference in New Issue View Git Blame Copy Permalink