Este documento explica todas as opções de metadados possíveis que você pode dar a seu model em sua class Meta.
If a model exists outside of the standard models.py (for instance, if the app’s models are in submodules of myapp.models), the model must define which app it is part of:
app_label = 'myapp'
O nome da tabela que será usado pelo model no banco de dados:
db_table = 'music_album'
Para poupar o seu tempo, o Django automaticamente deriva o nome das tabelas de banco de dados usando os nomes das classes models e da aplicação que o contém. O nomde de uma tabela de um model é construído juntando o "nome da app" do model -- o nome usado em manage.py startapp -- ao nome da classe do model, com um underscore entre eles.
Por exemplo, se você tem uma app bookstore (criada pelo manage.py startapp bookstore), um modelo definido como class Book terá uma tabela com o nome bookstore_book.
Para sobrescrever o nome da tabela, use o parametro db_table na class Meta.
Se o nome da sua tabela é uma palavra reservada do SQL, ou contém caracteres que não são permitidos em nomes de variáveis do Python -- notadamente, o hífen -- está OK. O Django colocará crases os nomes das colunas e tabelas sem você saber.
O nome do tablespace do banco dados utilizado para o model. Se o backend não suporta tablespaces, esta opção é ignorada.
O nome de um DateField ou DateTimeField no model. Isso especifica o campo padrão do seu model que será utilizado pelo método latest do Manager.
Exemplo:
get_latest_by = "order_date"
Veja a documentação para latest() para mais.
Defaults to True, meaning Django will create the appropriate database tables in syncdb and remove them as part of a reset management command. That is, Django manages the database tables' lifecycles.
If False, no database table creation or deletion operations will be performed for this model. This is useful if the model represents an existing table or a database view that has been created by some other means. This is the only difference when managed is False. All other aspects of model handling are exactly the same as normal. This includes
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.
If a model with managed=False contains a ManyToManyField that points to another unmanaged model, then the intermediate table for the many-to-many join will also not be created. However, a the intermediary table between one managed and one unmanaged model will be created.
If you need to change this default behavior, create the intermediary table as an explicit model (with managed set as needed) and use the ManyToManyField.through attribute to make the relation use your custom model.
For tests involving models with managed=False, it's up to you to ensure the correct tables are created as part of the test setup.
If you're interested in changing the Python-level behavior of a model class, you could use managed=False and create a copy of an existing model. However, there's a better approach for that situation: Proxy models.
Marca este objeto como "ordenável" em relação ao campo dado. Isso é quase sempre utilizado com objetos relacionados para permití-los ser ordenados a respeito de um objeto pai. Por exemplo, se um objeto Answer está relacionado a um objeto Question, e uma questão tem mais de uma resposta, e a ordem das respostas importa, você poderia fazer isso:
class Answer(models.Model):
question = models.ForeignKey(Question)
# ...
class Meta:
order_with_respect_to = 'question'
When order_with_respect_to is set, two additional methods are provided to retrieve and to set the order of the related objects: get_RELATED_order() and set_RELATED_order(), where RELATED is the lowercased model name. For example, assuming that a Question object has multiple related Answer objects, the list returned contains the primary keys of the related Answer objects:
>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]
The order of a Question object's related Answer objects can be set by passing in a list of Answer primary keys:
>>> question.set_answer_order([3, 1, 2])
The related objects also get two methods, get_next_in_order() and get_previous_in_order(), which can be used to access those objects in their proper order. Assuming the Answer objects are ordered by id:
>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>
O ordenamento padrão de um objeto, para usar quando obtem-se listas de objetos:
ordering = ['-order_date']
Isso é uma tupla ou lista de strings. Cada strin é o nomde de um campo com um prefixo opcional "-", que indica ordem descendente. Campos sem um "-" na frente serão ordenados ascendentemente. Use a string "?" para ordenar randomicamente.
Note
Indiferentemente de quão muitos sejam os campos em ordering, o admin usará somente o primeiro campo.
Por exemplo, para ordenar ascendentemente por um campo pub_date, use isto:
ordering = ['pub_date']
Para ordenar por pub_date descendentemente, use isto:
ordering = ['-pub_date']
Para ordenar por pub_date descendentemente, e por author ascendentemente, use isto:
ordering = ['-pub_date', 'author']
Para adicionar permissões extras na tabela de permissões quando criar este objeto. Permissões para adicionar, deletar e editar são automaticamente criadas para cada objeto que use o admin. Este exemplo expecifica uma permissão extra can_deliver_pizzas:
permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)
Isso é uma lista ou tupla de tuplas duplas no formato (código_da_permissão, nome_da_permissão_legível_por_humanos).
If set to True, a model which subclasses another model will be treated as a proxy model.
Seta os nomes de campos, que juntos, devem ser únicos:
unique_together = (("driver", "restaurant"),)
Isso é uma lista de listas de campos que devem ser únicos quando estão juntos. ela é usada no Django admin e é executada a nível de banco de dados (i.e., a regra UNIQUE apropriada é incluída na consulta CREATE TABLE).
Por conveniência, unique_together pode ser uma lista singular quando lida com camos sozinhos:
unique_together = ("driver", "restaurant")
Um nome legível-por-humanos para o objeto, no singular:
verbose_name = "pizza"
Se este não for fornecido, o Django usará uma versão do nome da classe: CamelCase se torna camel case.
O nome no plural para o objeto:
verbose_name_plural = "stories"
Se este não for fornecido, o Django usará verbose_name + "s".
Dec 26, 2011