元選項 · Django 中文文檔 1.8

# 模型元選項 # 這篇文檔闡述了所有可用的元選項，你可以在你模型的Meta類中設置他們。 ## 可用的元選項 ## ### abstract ### **Options.abstract** 如果 abstract = True，就表示模型是抽象基類 (abstract base class). ### app_label ### **Options.app_label** 如果你的模型定義在默認的 models.py 之外(比如，你現在用的模型在 myapp.models 子模塊當中)，你必須告訴 Django 該模型屬于哪個應用： ``` app_label = 'myapp' ``` ``` Django 1.7中新增：一個應用中，定義在models 模塊以外的模型，不再需要app_label。 ``` ### db_table ### **Options.db_table** 該模型所用的數據表的名稱： ``` db_table = 'music_album' ``` #### 數據表名稱 #### 為了節省時間，Django 會根據模型類的名稱和包含它的app名稱自動指定數據表名稱，一個模型的數據表名稱，由這個模型的“應用標簽”（在 manage.py startapp中使用的名稱）之間加上下劃線組成。舉個例子， bookstore應用(使用 manage.py startapp bookstore 創建)，里面有個名為 Book的模型，那數據表的名稱就是 bookstore_book 。使用 Meta類中的 db_table 參數來覆寫數據表的名稱。數據表名稱可以是 SQL 保留字，也可以包含不允許出現在 Python 變量中的特殊字符，這是因為 Django 會自動給列名和表名添加引號。 > 在 MySQL中使用小寫字母為表命名 > > 當你通過db_table覆寫表名稱時，強烈推薦使用小寫字母給表命名，特別是如果你用了MySQL作為后端。詳見MySQL注意事項。 > Oracle中表名稱的引號處理 > > 為了遵從Oracle中30個字符的限制，以及一些常見的約定，Django會縮短表的名稱，而且會把它全部轉為大寫。在db_table的值外面加上引號來避免這種情況： > ``` db_table = '"name_left_in_lowercase"' ``` > > 這種帶引號的名稱也可以用于Django所支持的其他數據庫后端，但是除了Oracle，引號不起任何作用。詳見 Oracle 注意事項。 ### db_tablespace ### **Options.db_tablespace** 當前模型所使用的數據庫表空間的名字。默認值是項目設置中的DEFAULT_TABLESPACE，如果它存在的話。如果后端并不支持表空間，這個選項可以忽略。 ### default_related_name ### **Options.default_related_name** ``` Django 1.8中新增： ``` 這個名字會默認被用于一個關聯對象到當前對象的關系。默認為 <model_name>_set。由于一個字段的反轉名稱應該是唯一的，當你給你的模型設計子類時，要格外小心。為了規避名稱沖突，名稱的一部分應該含有'%(app_label)s'和'%(model_name)s'，它們會被應用標簽的名稱和模型的名稱替換，二者都是小寫的。詳見抽象模型的關聯名稱。 ### 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命令中創建合適的數據表，并且會在 flush 管理命令中移除它們。換句話說，Django會管理這些數據表的生命周期。如果是False，Django 就不會為當前模型創建和刪除數據表。如果當前模型表示一個已經存在的，通過其它方法建立的數據庫視圖或者數據表，這會相當有用。這是設置為managed=False時唯一的不同之處。. 模型處理的其它任何方面都和平常一樣。這包括： + 如果你不聲明它的話，會向你的模型中添加一個自增主鍵。為了避免給后面的代碼讀者帶來混亂，強烈推薦你在使用未被管理的模型時，指定數據表中所有的列。 + 如果一個帶有managed=False的模型含有指向其他未被管理模型的ManyToManyField，那么多對多連接的中介表也不會被創建。但是，一個被管理模型和一個未被管理模型之間的中介表會被創建。如果你需要修改這一默認行為，創建中介表作為顯式的模型（設置為managed），并且使用ManyToManyField.through為你的自定義模型創建關聯。對于帶有managed=False的模型的測試，你要確保在測試啟動時建立正確的表。如果你對修改模型類在Python層面的行為感興趣，你可以設置 managed=False ，并且創建一個已經存在模型的部分。但是這種情況下使用代理模型才是更好的方法。 ### order_with_respect_to ### **Options.order_with_respect_to** 按照給定的字段把這個對象標記為”可排序的“。這一屬性通常用到關聯對象上面，使它在父對象中有序。比如，如果Answer和 Question相關聯，一個問題有至少一個答案，并且答案的順序非常重要，你可以這樣做： ``` 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 設置之后，模型會提供兩個用于設置和獲取關聯對象順序的方法：get_RELATED_order() 和set_RELATED_order()，其中RELATED是小寫的模型名稱。例如，假設一個 Question 對象有很多相關聯的Answer對象，返回的列表中含有相關聯Answer對象的主鍵： ``` >>> question = Question.objects.get(id=1) >>> question.get_answer_order() [1, 2, 3] ``` 與Question對象相關聯的Answer對象的順序，可以通過傳入一格包含Answer 主鍵的列表來設置： ``` >>> question.set_answer_order([3, 1, 2]) ``` 相關聯的對象也有兩個方法， 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屬性會添加一個額外的字段（/數據表中的列）叫做_order，所以如果你在首次遷移之后添加或者修改了order_with_respect_to屬性，要確保執行和應用了合適的遷移操作。 ### ordering ### **Options.ordering** 對象默認的順序，獲取一個對象的列表時使用： ``` ordering = ['-order_date'] ``` 它是一個字符串的列表或元組。每個字符串是一個字段名，前面帶有可選的“-”前綴表示倒序。前面沒有“-”的字段表示正序。使用"?"來表示隨機排序。例如，要按照pub_date字段的正序排序，這樣寫： ``` ordering = ['pub_date'] ``` 按照pub_date字段的倒序排序，這樣寫： ``` ordering = ['-pub_date'] ``` 先按照pub_date的倒序排序，再按照 author 的正序排序，這樣寫： ``` ordering = ['-pub_date', 'author'] ``` > 警告 > > 排序并不是沒有任何代價的操作。你向ordering屬性添加的每個字段都會產生你數據庫的開銷。你添加的每個外鍵也會隱式包含它的默認順序。 ### permissions ### **Options.permissions** 設置創建對象時權限表中額外的權限。增加、刪除和修改權限會自動為每個模型創建。這個例子指定了一種額外的權限，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命令創建之前，這個屬性必須被指定，以防一些遺漏的屬性被創建。 ### 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觸發器會返回NULL。這種情況下，新式的算法會在最后執行 INSERT 操作，即使這一行已經在數據庫中存在。通常這個屬性不需要設置。默認為False。關于舊式和新式兩種算法，請參見django.db.models.Model.save()。 ### unique_together ### **Options.unique_together** 用來設置的不重復的字段組合： ``` unique_together = (("driver", "restaurant"),) ``` 它是一個元組的元組，組合起來的時候必須是唯一的。它在Django后臺中被使用，在數據庫層上約束數據(比如，在 CREATE TABLE 語句中包含 UNIQUE語句)。為了方便起見，處理單一字段的集合時，unique_together 可以是一維的元組： ``` unique_together = ("driver", "restaurant") ``` ManyToManyField不能包含在unique_together中。（這意味著什么并不清楚！）如果你需要驗證ManyToManyField關聯的唯一性，試著使用信號或者顯式的貫穿模型(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** 對象的一個易于理解的名稱，為單數： ``` verbose_name = "pizza" ``` 如果此項沒有設置，Django會把類名拆分開來作為自述名，比如CamelCase 會變成camel case， ### verbose_name_plural ### **Options.verbose_name_plural** 該對象復數形式的名稱： ``` verbose_name_plural = "stories" ``` 如果此項沒有設置，Django 會使用 verbose_name + "s"。