.. .. META INFORMATION OF TRANSLATION .. .. $TranslationStatus: Done, waiting for revision $ .. $OriginalRevision: 14849 $ .. $TranslationAuthors: Robson Mendonça $ .. .. INFO OF THIS FILE (DO NOT EDIT! UPDATED BY SUBVERSION) .. .. $HeadURL$ .. $LastChangedRevision$ .. $LastChangedBy$ .. $LastChangedDate$ .. .. _ref-models-options: ======================== ``Meta`` opções do model ======================== Este documento explica todas as :ref:`opções de metadados ` possíveis que você pode dar a seu model em sua ``class Meta``. Opções disponíveis do ``Meta`` ============================== .. currentmodule:: django.db.models ``abstract`` ------------ .. attribute:: Options.abstract Se ``True``, este model será um :ref:`uma classe abstrata básica `. ``app_label`` ------------- .. attribute:: Options.app_label If a model exists outside of the standard :file:`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' ``db_table`` ------------ .. attribute:: Options.db_table O nome da tabela que será usado pelo model no banco de dados:: db_table = 'music_album' .. _table-names: Nomes de tabelas ~~~~~~~~~~~~~~~~ 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. ``db_tablespace`` ----------------- .. attribute:: Options.db_tablespace .. versionadded:: 1.0 O nome do tablespace do banco dados utilizado para o model. Se o backend não suporta tablespaces, esta opção é ignorada. ``get_latest_by`` ----------------- .. attribute:: Options.get_latest_by O nome de um :class:`DateField` ou :class:`DateTimeField` no model. Isso especifica o campo padrão do seu model que será utilizado pelo método :class:`~QuerySet.latest` do :class:`Manager`. Exemplo:: get_latest_by = "order_date" Veja a documentação para :meth:`~django.db.models.QuerySet.latest` para mais. ``managed`` ----------------------- .. attribute:: Options.managed .. versionadded:: 1.1 Defaults to ``True``, meaning Django will create the appropriate database tables in :djadmin:`syncdb` and remove them as part of a :djadmin:`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 1. 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. 2. If a model with ``managed=False`` contains a :class:`~django.db.models.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 :attr:`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: :ref:`proxy-models`. ``order_with_respect_to`` ------------------------- .. attribute:: Options.order_with_respect_to 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.get_previous_in_order() ``ordering`` ------------ .. attribute:: Options.ordering 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 :attr:`~Options.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'] ``permissions`` --------------- .. attribute:: Options.permissions 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)``. ``proxy`` --------- .. attribute:: Options.proxy .. versionadded:: 1.1 If set to ``True``, a model which subclasses another model will be treated as a :ref:`proxy model `. ``unique_together`` ------------------- .. attribute:: Options.unique_together 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``). .. versionadded:: 1.0 Por conveniência, unique_together pode ser uma lista singular quando lida com camos sozinhos:: unique_together = ("driver", "restaurant") ``verbose_name`` ---------------- .. attribute:: Options.verbose_name 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``. ``verbose_name_plural`` ----------------------- .. attribute:: Options.verbose_name_plural O nome no plural para o objeto:: verbose_name_plural = "stories" Se este não for fornecido, o Django usará :attr:`~Options.verbose_name` + ``"s"``.