1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
.. _ref-models-options:
======================
Model ``Meta`` options
======================
This document explains all the possible :ref:`metadata options <meta-options>` that you can give your model in its internal
``class Meta``.
Available ``Meta`` options
==========================
.. currentmodule:: django.db.models
``abstract``
------------
.. attribute:: Options.abstract
If ``True``, this model will be an :ref:`abstract base class <abstract-base-classes>`.
``db_table``
------------
.. attribute:: Options.db_table
The name of the database table to use for the model::
db_table = 'music_album'
.. _table-names:
Table names
~~~~~~~~~~~
To save you time, Django automatically derives the name of the database table
from the name of your model class and the app that contains it. A model's
database table name is constructed by joining the model's "app label" -- the
name you used in ``manage.py startapp`` -- to the model's class name, with an
underscore between them.
For example, if you have an app ``bookstore`` (as created by
``manage.py startapp bookstore``), a model defined as ``class Book`` will have
a database table named ``bookstore_book``.
To override the database table name, use the ``db_table`` parameter in
``class Meta``.
If your database table 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_tablespace``
-----------------
.. attribute:: Options.db_tablespace
.. versionadded:: 1.0
The name of the database tablespace to use for the model. If the backend doesn't
support tablespaces, this option is ignored.
``get_latest_by``
-----------------
.. attribute:: Options.get_latest_by
The name of a :class:`DateField` or :class:`DateTimeField` in the model. This
specifies the default field to use in your model :class:`Manager`'s
:class:`~QuerySet.latest` method.
Example::
get_latest_by = "order_date"
See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
``order_with_respect_to``
-------------------------
.. attribute:: Options.order_with_respect_to
Marks this object as "orderable" with respect to the given field. This is almost
always used with related objects to allow them to be ordered with respect to a
parent object. For example, if an ``Answer`` relates to a ``Question`` object,
and a question has more than one answer, and the order of answers matters, you'd
do this::
class Answer(models.Model):
question = models.ForeignKey(Question)
# ...
class Meta:
order_with_respect_to = 'question'
``ordering``
------------
.. attribute:: Options.ordering
The default ordering for the object, for use when obtaining lists of objects::
ordering = ['-order_date']
This is a tuple or list of strings. Each string is a field name with an optional
"-" prefix, which indicates descending order. Fields without a leading "-" will
be ordered ascending. Use the string "?" to order randomly.
.. note::
Regardless of how many fields are in :attr:`~Options.ordering`, the admin
site uses only the first field.
For example, to order by a ``pub_date`` field ascending, use this::
ordering = ['pub_date']
To order by ``pub_date`` descending, use this::
ordering = ['-pub_date']
To order by ``pub_date`` descending, then by ``author`` ascending, use this::
ordering = ['-pub_date', 'author']
``permissions``
---------------
.. attribute:: Options.permissions
Extra permissions to enter into the permissions table when creating this object.
Add, delete and change permissions are automatically created for each object
that has ``admin`` set. This example specifies an extra permission,
``can_deliver_pizzas``::
permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)
This is a list or tuple of 2-tuples in the format ``(permission_code,
human_readable_permission_name)``.
``unique_together``
-------------------
.. attribute:: Options.unique_together
Sets of field names that, taken together, must be unique::
unique_together = (("driver", "restaurant"),)
This is a list of lists of fields that must be unique when considered together.
It's used in the Django admin and is enforced at the database level (i.e., the
appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE``
statement).
.. versionadded:: 1.0
For convenience, unique_together can be a single list when dealing with a single
set of fields::
unique_together = ("driver", "restaurant")
``verbose_name``
----------------
.. attribute:: Options.verbose_name
A human-readable name for the object, singular::
verbose_name = "pizza"
If this isn't given, Django will use a munged version of the class name:
``CamelCase`` becomes ``camel case``.
``verbose_name_plural``
-----------------------
.. attribute:: Options.verbose_name_plural
The plural name for the object::
verbose_name_plural = "stories"
If this isn't given, Django will use :attr:`~Options.verbose_name` + ``"s"``.
|
