這篇文檔闡述了所有可用的元選項，你可以在你模型的Meta類中設置他們。

可用的元選項

abstract

Options.abstract

如果 abstract = True， 就表示模型是 抽象基類 (abstract base class).

app_label

Options.app_label

如果你的模型定義在默認的 models.py 之外(比如，你現(xiàn)在用的模型在 myapp.models 子模塊當中)，你必須告訴 Django 該模型屬于哪個應用：

app_label = 'myapp'

Django 1.7中新增：

一個應用中，定義在models 模塊以外的模型，不再需要app_label。

db_table

Options.db_table

該模型所用的數(shù)據(jù)表的名稱：

db_table = 'music_album'

數(shù)據(jù)表名稱

為了節(jié)省時間，Django 會根據(jù)模型類的名稱和包含它的app名稱自動指定數(shù)據(jù)表名稱，一個模型的數(shù)據(jù)表名稱，由這個模型的“應用標簽”（在 manage.py startapp中使用的名稱）之間加上下劃線組成。

舉個例子， bookstore應用(使用 manage.py startapp bookstore 創(chuàng)建)，里面有個名為 Book的模型，那數(shù)據(jù)表的名稱就是 bookstore_book 。

使用 Meta類中的 db_table 參數(shù)來覆寫數(shù)據(jù)表的名稱。

數(shù)據(jù)表名稱可以是 SQL 保留字，也可以包含不允許出現(xiàn)在 Python 變量中的特殊字符，這是因為 Django 會自動給列名和表名添加引號。

在 MySQL中使用小寫字母為表命名

當你通過db_table覆寫表名稱時，強烈推薦使用小寫字母給表命名，特別是如果你用了MySQL作為后端。詳見MySQL注意事項 。

Oracle中表名稱的引號處理

為了遵從Oracle中30個字符的限制，以及一些常見的約定，Django會縮短表的名稱，而且會把它全部轉為大寫。在db_table的值外面加上引號來避免這種情況：

db_table = '"name_left_in_lowercase"'

這種帶引號的名稱也可以用于Django所支持的其他數(shù)據(jù)庫后端，但是除了Oracle，引號不起任何作用。詳見 Oracle 注意事項 。

db_tablespace

Options.db_tablespace

當前模型所使用的數(shù)據(jù)庫表空間 的名字。默認值是項目設置中的DEFAULT_TABLESPACE，如果它存在的話。如果后端并不支持表空間，這個選項可以忽略。

default_related_name

Options.default_related_name

Django 1.8中新增：

這個名字會默認被用于一個關聯(lián)對象到當前對象的關系。默認為 _set。

由于一個字段的反轉名稱應該是唯一的，當你給你的模型設計子類時，要格外小心。為了規(guī)避名稱沖突，名稱的一部分應該含有'%(app_label)s'和'%(model_name)s'，它們會被應用標簽的名稱和模型的名稱替換，二者都是小寫的。詳見抽象模型的關聯(lián)名稱。

get_latest_by

Options.get_latest_by

模型中某個可排序的字段的名稱，比如DateField、DateTimeField或者IntegerField。它指定了Manager的latest()和earliest()中使用的默認字段。

例如：

get_latest_by = "order_date"

詳見latest() 文檔。

managed

Options.managed

默認為True，意思是Django在migrate命令中創(chuàng)建合適的數(shù)據(jù)表，并且會在 flush 管理命令中移除它們。換句話說，Django會管理這些數(shù)據(jù)表的生命周期。

如果是False，Django 就不會為當前模型創(chuàng)建和刪除數(shù)據(jù)表。如果當前模型表示一個已經(jīng)存在的，通過其它方法建立的數(shù)據(jù)庫視圖或者數(shù)據(jù)表，這會相當有用。這是設置為managed=False時唯一的不同之處。. 模型處理的其它任何方面都和平常一樣。這包括：

• 如果你不聲明它的話，會向你的模型中添加一個自增主鍵。為了避免給后面的代碼讀者帶來混亂，強烈推薦你在使用未被管理的模型時，指定數(shù)據(jù)表中所有的列。
• 如果一個帶有managed=False的模型含有指向其他未被管理模型的ManyToManyField，那么多對多連接的中介表也不會被創(chuàng)建。但是，一個被管理模型和一個未被管理模型之間的中介表會被創(chuàng)建。

如果你需要修改這一默認行為，創(chuàng)建中介表作為顯式的模型（設置為managed），并且使用ManyToManyField.through為你的自定義模型創(chuàng)建關聯(lián)。

對于帶有managed=False的模型的測試，你要確保在測試啟動時建立正確的表。

如果你對修改模型類在Python層面的行為感興趣，你可以設置 managed=False ，并且創(chuàng)建一個已經(jīng)存在模型的部分。但是這種情況下使用代理模型才是更好的方法。

order_with_respect_to

Options.order_with_respect_to

按照給定的字段把這個對象標記為”可排序的“。這一屬性通常用到關聯(lián)對象上面，使它在父對象中有序。比如，如果Answer和 Question相關聯(lián)，一個問題有至少一個答案，并且答案的順序非常重要，你可以這樣做：

from django.db import models

class Question(models.Model):
    text = models.TextField()
    # ...

class Answer(models.Model):
    question = models.ForeignKey(Question)
    # ...

    class Meta:
        order_with_respect_to = 'question'

當order_with_respect_to 設置之后，模型會提供兩個用于設置和獲取關聯(lián)對象順序的方法：get_RELATED_order() 和set_RELATED_order()，其中RELATED是小寫的模型名稱。例如，假設一個 Question 對象有很多相關聯(lián)的Answer對象，返回的列表中含有相關聯(lián)Answer對象的主鍵：

>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]

與Question對象相關聯(lián)的Answer對象的順序，可以通過傳入一格包含Answer 主鍵的列表來設置：

>>> question.set_answer_order([3, 1, 2])

相關聯(lián)的對象也有兩個方法， get_next_in_order() 和get_previous_in_order()，用于按照合適的順序訪問它們。假設Answer對象按照 id來排序：

>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>

修改 order_with_respect_to

order_with_respect_to屬性會添加一個額外的字段（/數(shù)據(jù)表中的列）叫做_order，所以如果你在首次遷移之后添加或者修改了order_with_respect_to屬性，要確保執(zhí)行和應用了合適的遷移操作。

ordering

Options.ordering

對象默認的順序，獲取一個對象的列表時使用：

ordering = ['-order_date']

它是一個字符串的列表或元組。每個字符串是一個字段名，前面帶有可選的“-”前綴表示倒序。前面沒有“-”的字段表示正序。使用"?"來表示隨機排序。

例如，要按照pub_date字段的正序排序，這樣寫：

ordering = ['pub_date']

按照pub_date字段的倒序排序，這樣寫：

ordering = ['-pub_date']

先按照pub_date的倒序排序，再按照 author 的正序排序，這樣寫：

ordering = ['-pub_date', 'author']

警告

排序并不是沒有任何代價的操作。你向ordering屬性添加的每個字段都會產(chǎn)生你數(shù)據(jù)庫的開銷。你添加的每個外鍵也會隱式包含它的默認順序。

permissions

Options.permissions

設置創(chuàng)建對象時權限表中額外的權限。增加、刪除和修改權限會自動為每個模型創(chuàng)建。這個例子指定了一種額外的權限，can_deliver_pizzas：

permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)

它是一個包含二元組的元組或者列表，格式為 (permission_code, human_readable_permission_name)。

default_permissions

Options.default_permissions

Django 1.7中新增：

默認為('add', 'change', 'delete')。你可以自定義這個列表，比如，如果你的應用不需要默認權限中的任何一項，可以把它設置成空列表。在模型被migrate命令創(chuàng)建之前，這個屬性必須被指定，以防一些遺漏的屬性被創(chuàng)建。

proxy

Options.proxy

如果proxy = True, 作為該模型子類的另一個模型會被視為代理模型。

select_on_save

Options.select_on_save

該選項決定了Django是否采用1.6之前的 django.db.models.Model.save()算法。舊的算法使用SELECT來判斷是否存在需要更新的行。而新式的算法直接嘗試使用 UPDATE。在一些小概率的情況中，一個已存在的行的UPDATE操作并不對Django可見。比如PostgreSQL的ON UPDATE觸發(fā)器會返回NULL。這種情況下，新式的算法會在最后執(zhí)行 INSERT 操作，即使這一行已經(jīng)在數(shù)據(jù)庫中存在。

通常這個屬性不需要設置。默認為False。

關于舊式和新式兩種算法，請參見django.db.models.Model.save()。

unique_together

Options.unique_together

用來設置的不重復的字段組合：

unique_together = (("driver", "restaurant"),)

它是一個元組的元組，組合起來的時候必須是唯一的。它在Django后臺中被使用，在數(shù)據(jù)庫層上約束數(shù)據(jù)(比如，在 CREATE TABLE 語句中包含 UNIQUE語句)。

為了方便起見，處理單一字段的集合時，unique_together 可以是一維的元組：

unique_together = ("driver", "restaurant")

ManyToManyField不能包含在unique_together中。（這意味著什么并不清楚！）如果你需要驗證ManyToManyField關聯(lián)的唯一性，試著使用信號或者顯式的貫穿模型(explicit through model)。

Django 1.7中修改：
當unique_together的約束被違反時，模型校驗期間會拋出ValidationError異常。

index_together

Options.index_together

用來設置帶有索引的字段組合：

index_together = [
    ["pub_date", "deadline"],
]

列表中的字段將會建立索引（例如，會在CREATE INDEX語句中被使用）。

Django 1.7中修改：

為了方便起見，處理單一字段的集合時，index_together可以是一個一維的列表。

index_together = ["pub_date", "deadline"]

verbose_name

Options.verbose_name

對象的一個易于理解的名稱，為單數(shù)：

verbose_name = "pizza"

如果此項沒有設置，Django會把類名拆分開來作為自述名，比如CamelCase 會變成camel case，

verbose_name_plural

Options.verbose_name_plural

該對象復數(shù)形式的名稱：

verbose_name_plural = "stories"

如果此項沒有設置，Django 會使用 verbose_name + "s"。