Um modelo é um único e definitiva fonte de dados sobre os seus dados, Ele contém os campos e comportamentos essenciais dos dados que você está armazenando. Em geral, cada modelo mapeia para uam única tabela no seu banco de dados.
\nO básico
\nCada modelo é uma classe Python que herda django.db.models.Model.
Cada atributo de um modelo representa um campo no banco de dados.
Com tudo isso, Django lhe dá uma API de acesso ao banco de dados gerada automaticamente; veja Fazendo consultas.
Neste exemplo o modelo define um Person, o qual tem um first_name``e ``last_name:
from django.db import models\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=30)\n last_name = models.CharField(max_length=30)\nfirst_name e last_name são “fields” do modelo. Cada campo é especificado como um atributo de classe, e cada atributo mapeia uma coluna do banco de dados.
O modelo Person criaria uma tabela de banco de dados como esta:
CREATE TABLE myapp_person (\n "id" serial NOT NULL PRIMARY KEY,\n "first_name" varchar(30) NOT NULL,\n "last_name" varchar(30) NOT NULL\n);\nAlgumas notas técnicas:
\nO nome da tabela, myapp_person, é automaticamente derivado de alguns metadados do modelo mas pode ser sibrescrito. Veja Table names para mais detalhes.
Um campo id é adicionado automaticamente, mas este comportamento pode ser sobrescrito. Veja Campos chave-primária automáticos..
O SQL CREATE TABLE neste exemplo está formatado usando a syntax do PostgreSQL, mas vale a pena notar que o Django usa SQL de acordo com o “backend” do banco de dados especificado no seu arquivo de definições.
Uma vez que tenha definido seus modelos, você precisa dizer ao Django que irá usar aqueles modelos. Faça isso editando seu arquivo de definições e alterando a definição do INSTALLED_APPS para adicionar o nome do módulo que contém seu models.py.
Por exemplo, se o modelo para sua aplicação está em um módulo myapp.models (a estrutura de pacote que foi criada para uma aplicação pelo script manage.py startapp), INSTALLED_APPS deve ser lido, em parte:
INSTALLED_APPS = [\n #...\n 'myapp',\n #...\n]\nQuando adicionar novas aplicações ao INSTALLED_APPS, tenha certeza de rodar manage.py migrate, opcionalmente antes fazendo migrações para eles antes com manage.py makemigrations.
A parte mais importante de um modelo – e a única parte requerida de um modelo – é a lista de campos de banco de dados que ele define. Campos são especificados através de atributos de classe. Cuidado para não escolher nomes de campos que conflitem com a API dos modelos like clean, save, ou delete.
Exemplo
\nfrom django.db import models\n\nclass Musician(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n instrument = models.CharField(max_length=100)\n\nclass Album(models.Model):\n artist = models.ForeignKey(Musician, on_delete=models.CASCADE)\n name = models.CharField(max_length=100)\n release_date = models.DateField()\n num_stars = models.IntegerField()\nCada campo no seu modelo deve ser instanciado da classe Field apropriada. O Django usa o tipo de classe do campo para determinar algumas coisas:
O tipo da coluna, o qual diz ao banco de dados que tipo de dado irá armazenar (e.g. INTEGER, VARCHAR, TEXT).
O widget HTML padrão para usar quando renderizar o campo de um form (ex. <input type="text">, <select>).
The minimal validation requirements, used in Django’s admin and in\nautomatically-generated forms.
Django vem com dúzias de tipos de campos; você pode achar uma lista nas refrências de campos de modelo. Você pode facilmente escrever seus próprios campos se os que vêm definidos no Django não resolverem; veja Escrevendo campos personalizados de modelos..
\nCada campo recebe um certo conjunto de argumentos específicos (documentados na referência de campos de modelo). Por exemplo, a CharField (e suas subclasses) requerem um argumento max_length o qual especifica o comprimento usado para armazenar dados do campo VARCHAR do banco de dados.
Também há um conjunto de argumentos comuns disponíveis para todos os tipos de campos. Todos opcionais. Estes argumentos são explicados na referência, mas aqui um sumário dos argumentos mais usados:
\nnullSe True, o Django irá usar valores “vazios” como NULL no banco de dados. Padrão is False.
blankSe True, é permitido o campo estar em “branco”. O padrão é False.
Note que isso é diferente de null. null é puramente relacionado ao banco de dados, enquanto que o blank é relacionado a validação. Se um campo tiver blank=True, a validação do “form” permitirá entrada de ym valor vazio. Se o campo tiver blank=False, o campo será requerido.
choicesUm iterável (ex.: lista de tuplas) de tuplas de 2 apra usar como opções para este campo. Assim sendo, o “widget” padrão será um “select box” no lugar de um campo de texto padrão e o campo se limitará às opções dadas.
\nUma lista de opções se parece com isso:
\nYEAR_IN_SCHOOL_CHOICES = (\n ('FR', 'Freshman'),\n ('SO', 'Sophomore'),\n ('JR', 'Junior'),\n ('SR', 'Senior'),\n ('GR', 'Graduate'),\n)\nO primeiro elemento em cada tupla é o valor que será armazenado no banco de dados. O segundo elemento será mostrado pelo “widget” de formulário padrão ou na ModelChoiceField. Dada uma instância de modelo, o valor a ser mostrado por campo “choice” pode ser acessado usando o método get_FOO_display(). Por exemplo:
from django.db import models\n\nclass Person(models.Model):\n SHIRT_SIZES = (\n ('S', 'Small'),\n ('M', 'Medium'),\n ('L', 'Large'),\n )\n name = models.CharField(max_length=60)\n shirt_size = models.CharField(max_length=1, choices=SHIRT_SIZES)\n>>> p = Person(name="Fred Flintstone", shirt_size="L")\n>>> p.save()\n>>> p.shirt_size\n'L'\n>>> p.get_shirt_size_display()\n'Large'\ndefaultO valor padrão para o campo. Este pode ser um valor ou um objeto “callable”. Se “callable” ele será chamado cada vez que um novo objeto for criado.
\nhelp_textTexto extra de ajuda para ser mostrado com o “widget” do formulário. É útil para documentar mesmo que seu campo não seja usado em um formulário.
\nprimary_keySe True, este campo será a chave-primária do seu modelo.
Se você não especificar o primary_key=True para qualquer campo no seu modelo, o Django irá automaticamente adicionar uma IntegerField para ser a chave-primária, e você não precisa definir primary_key=True em nenhum dos seus campos a menos que queria sobrescrever o comportamento padrão da chave-primária. Para mais, veja Campos chave-primária automáticos..
O campo chave-primária é somente para leitura. Se você alterar o valor de uma chave-primária em um objeto existente e salvá-lo, um novo objeto será criado além do antigo. Por exemplo:
\nfrom django.db import models\n\nclass Fruit(models.Model):\n name = models.CharField(max_length=100, primary_key=True)\n>>> fruit = Fruit.objects.create(name='Apple')\n>>> fruit.name = 'Pear'\n>>> fruit.save()\n>>> Fruit.objects.values_list('name', flat=True)\n['Apple', 'Pear']\nuniqueSe True, este campo deve ser único dentro da tabela
Novamente, estas são apenas descrições curtas das opções mais comuns dos campos. Detalhes completos podem ser encontrados na ref:referência de opções de campos de modelos comuns <common-model-field-options>.
\nPor padrão, o DJango dá a cada modelo o seguinte campo:
\nid = models.AutoField(primary_key=True)\nEste é um campo chave-primária de incremento automático.
\nSe quiser implementar uma chave-primária personalizada, apenas especifique primary_key=True em um de seus campos. Se o Django vir que você explicitamente definiu Field.primary_key, ele não adicionará uma coluna ``id``automaticamente.
Cada modelo requere exatamente um campo que tenha primary_key=True (declarado explicitamente ou adicionado automaticamente).
Cada tipo de campo, exceto para ForeignKey, ManyToManyField e OneToOneField, recebe um argumento opcional como primeiro argumento – um nome detalhado. Se o nome detalhado não for informado, o Django irá automaticamente criar ele usando o atributo nome do campos, convertendo “underscores” para espaços.
Neste exemplo, o nome detalhada é "person's first name":
first_name = models.CharField("person's first name", max_length=30)\nNeste exemplo, o nome detalhado é "first name":
first_name = models.CharField(max_length=30)\nForeignKey, ManyToManyField and OneToOneField requerem que o primeiro argumento seja uma classe de modelo, então use o argumento nomeado verbose_name:
poll = models.ForeignKey(\n Poll,\n on_delete=models.CASCADE,\n verbose_name="the related poll",\n)\nsites = models.ManyToManyField(Site, verbose_name="list of sites")\nplace = models.OneToOneField(\n Place,\n on_delete=models.CASCADE,\n verbose_name="related place",\n)\nA convenção é não usar caixa-alta na primeira letra do verbose_name. O Django irá automaticamente captalizar a primeira letra quando for necessário.
Claramente, o poder dos bancos de dados relacionais está em relacionar as tabelas entre elas. O Django oferece maneiras de definir os três tipos de relacionamentos mais comuns: muitos-para-muitos, muitos-para-um e um-para-um.
\nPara definir um relacionamento de muitos-para-um, use django.db.models.ForeignKey. Você o usar como qualquer outro tipo de Field: incluindo-o como um atributo do seu modelo.
A ForeignKey requer um argumento posicional: a classe com a qual o modelo está relacionado.
Por exemplo, se um modelo Car tem um fabricante Manufacturer – quer dizer, um Manufacturer faz múltiplos carros mas cada Car somente tem um Manufacturer – use as seguintes definições:
from django.db import models\n\nclass Manufacturer(models.Model):\n # ...\n pass\n\nclass Car(models.Model):\n manufacturer = models.ForeignKey(Manufacturer, on_delete=models.CASCADE)\n # ...\nVocê também pode criar relacionamentos recursivos (um objeto com relacionamento muitos-para-um comsigo mesmo) e relacionamentos para modelos que ainda não foram definidos; veja a referência para campos de modelo para detalhes.
\nÉ sugerído, mas não requerido, que o nomde de um campo ForeignKey (``manufacturer``no nosso exemplo acima) seja o nome do modelo, em caixa baixa. Você pode, claro, chamar o campo como quiser. Por exemplo:
class Car(models.Model):\n company_that_makes_it = models.ForeignKey(\n Manufacturer,\n on_delete=models.CASCADE,\n )\n # ...\nPara definir relacionamentos muitos-para-muitos, use ManyToManyField. Você o usa tal como qualquer outro tipo de Field: incluindo-o como um atributo de classe no seu modelo
O ManyToManyField requer um argumento posicional: a classe com a qual o modelo está relacionado.
Por exemplo, se a Pizza tem muitos objetos Topping – quer dizer, um Topping pode ter em multiplas pizzas e cada Pizza tem muitos recheios – aqui está como você deveria representá-los:
from django.db import models\n\nclass Topping(models.Model):\n # ...\n pass\n\nclass Pizza(models.Model):\n # ...\n toppings = models.ManyToManyField(Topping)\nTal como ForeignKey, você também pode criar relacionamentos recursivos (um objeto com relacionamento muitos-para-muitos com ele mesmo) e relacionamentos com modelos ainda não definidos.
É sugerido, mas não requerido que o nome de um ManyToManyField (toppings no nosso exemplo acima) seja um plural descrevendo o conjunto dos objetos relacionados do modelo.
Não importa quais dos modelos tem a ManyToManyField, mas você deve colocá-la somente em um dos modelos – não em ambos.
Geralmente, instancias de ManyToManyField devem ir no objeto que serão editados em um formulário. No exemplo acima, toppings está na Pizza (ao invés de Topping ter pizzas como ManyToManyField ) porque é mais natural pensar sobre pizza tendo recheio do que recheios estando em múltiplas pizzas. A maneira com está definido acima, o formulário de Pizza deveria deixar usuários selecionar os recheios.
ManyToManyField os campos também aceitam vários argumentos extras como explicado na referência de campos de modelo. Estas opções ajudam a definir como o relacionamento deve funcionar; todos são opcionais.
Quando você está lidando com relacionamentos muitos-para-muitos simples tal como combinar pizzas e recheios, tudo o que você precisa é um ManyToManyField padrão. Porém, algumas vezes você quer associar dados com o relacionamento entre dois modelos.
Por exemplo, considere o caso de uma aplicação que rastreia grupos musicais aos quais pertencem músicos. Existe um relacionamento muitos-para-muitos entre pessoas e grupos aos quais eles são membros, então você poderia usar uma ManyToManyField para representar este relacionamento. Porém, existem váriios detalhes sobre este relacionamento que você talvez queria coletar, tal como a data na qual a pessoa se juntou ao grupo.
Para estas situações, o Django permite que você especifique o modelo que será usado para “governar” o relacionamento muitos-para-muitos. Você pode então colocar campos extras no modelo intermediário. O modelo intermediário está associado a ManyToManyField usando o argumento through para apontar para o modelo que atuará como um intermediário. Para nosso exemplo de músicos, o código poderia parecer como algo como:
from django.db import models\n\nclass Person(models.Model):\n name = models.CharField(max_length=128)\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\n\nclass Group(models.Model):\n name = models.CharField(max_length=128)\n members = models.ManyToManyField(Person, through='Membership')\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\n\nclass Membership(models.Model):\n person = models.ForeignKey(Person, on_delete=models.CASCADE)\n group = models.ForeignKey(Group, on_delete=models.CASCADE)\n date_joined = models.DateField()\n invite_reason = models.CharField(max_length=64)\nQuando você define um modelo intermediário, você especifica explicitamente chaves-estrangeiras para os modelos que estão envolvidos no relacionamento muitos-para-muitos. Esta declaração explícita define como os dois modelos estão relacionados.
\nExistem algumas poucas restrições sobre os modelos intermediários.
\nSeu modelo intermediário deve ter uma - e * somente* uma - chave estrangeira para o modelo fonte (no nosso exemplo, este deve ser o Group), ou você deverá especificar explicitamente as chaves-estrangeiras que o Django deve usar para o relacionamento usando o ManyToManyField.through_fields. Se você tiver mais de uma chave-estrangeira e through_fields não estiver especificado, um erro de validação será emitido. Uma restrição similar se aplica para a chave-estrangeira para o modelo alvo (no nosso exemplo, este deve ser o Person).
Para um modelo que tenha um relacionamento muitos-para-muitos para ele mesmo através de um modelo intermediário, é permitido duas chaves-estrangeiras para o mesmo modelo, mas elas serão tratadas como os dois lados (diferentes) do relacionamento muitos-para-muitos. Se houver mais de duas chaves-estrangeiras, você também deve especificar o through_fields como acima, ou um erro de validação será emitido.
Quando definir uma relaçao muito-para-muitos de um modelo para ele mesmo, usando um modelo intermediário, você deve usar o symmetrical=False (veja referência de campos de modelos).
Agora que você definiu sua ManyToManyField para usar seu modelo intermediário (neste caso, Membership), você está pronto para começar a criar alguns relacionamentos muitos-para-muitos. Você faz isso criando instâncias do modelo intermediário.
>>> ringo = Person.objects.create(name="Ringo Starr")\n>>> paul = Person.objects.create(name="Paul McCartney")\n>>> beatles = Group.objects.create(name="The Beatles")\n>>> m1 = Membership(person=ringo, group=beatles,\n... date_joined=date(1962, 8, 16),\n... invite_reason="Needed a new drummer.")\n>>> m1.save()\n>>> beatles.members.all()\n[<Person: Ringo Starr>]\n>>> ringo.group_set.all()\n[<Group: The Beatles>]\n>>> m2 = Membership.objects.create(person=paul, group=beatles,\n... date_joined=date(1960, 8, 1),\n... invite_reason="Wanted to form a band.")\n>>> beatles.members.all()\n[<Person: Ringo Starr>, <Person: Paul McCartney>]\nDiferente dos campos muitos-para-muitos normais, você não pode usar add, create ou atribuições (isto é, beatles.members = [...]) para criar relacionamentos:
# THIS WILL NOT WORK\n>>> beatles.members.add(john)\n# NEITHER WILL THIS\n>>> beatles.members.create(name="George Harrison")\n# AND NEITHER WILL THIS\n>>> beatles.members = [john, paul, ringo, george]\nPorque ? Você nã pode criar simplesmente um relacionamento entre um Person``e um ``Group - você precisa especificar todos os detalhes requeridos para o relacionamento através do modelo Membership. O add, create e a chamadas para atribuições simples não fornecem um meio de especificar os detalhes extras. Como resultado, eles não estão habilitados para um relacionamento muitos-para-muitos que usam um modelo intermediário. A única maneira de criar este tipo de relacioanmento é criar instâncias do modelo intermediário.
O método remove() não está habilitado por razões similares. Contudo, o método clear() pode ser usado para remover todas os relacionamentos muitos-para-muitos de uma instância.
>>> # Beatles have broken up\n>>> beatles.members.clear()\n>>> # Note that this deletes the intermediate model instances\n>>> Membership.objects.all()\n[]\nUma vez que tenha estabelecido o relacionamento muitos-para-muitos através da criação do seu modelo intermediário, você pode fazer consultas. Tal como um relacionamento muitos-para-muitos normal, você pode fazer consultas usando os atributos do modelo muitos-para-muitos relacionado.
\n# Find all the groups with a member whose name starts with 'Paul'\n>>> Group.objects.filter(members__name__startswith='Paul')\n[<Group: The Beatles>]\nComo está usando um modelo intemerdiário, você pode também fazer consultas em seus atributos:
\n# Find all the members of the Beatles that joined after 1 Jan 1961\n>>> Person.objects.filter(\n... group__name='The Beatles',\n... membership__date_joined__gt=date(1961,1,1))\n[<Person: Ringo Starr]\nSe você precisa de acessar informações do membro você pode fazê-lo diretamente consultando o modelo Membership:
>>> ringos_membership = Membership.objects.get(group=beatles, person=ringo)\n>>> ringos_membership.date_joined\ndatetime.date(1962, 8, 16)\n>>> ringos_membership.invite_reason\n'Needed a new drummer.'\nOutra maneira de acessa a mesma informação é através da consulta do relacionamento muitos-para-muitos reverse de um objeto Person:
>>> ringos_membership = ringo.membership_set.get(group=beatles)\n>>> ringos_membership.date_joined\ndatetime.date(1962, 8, 16)\n>>> ringos_membership.invite_reason\n'Needed a new drummer.'\nPara definir um relacionamento um-para-um, use a OneToOneField. Você pode usar como qualquer outro tipo Field: incluindo-o como um atributo de classe do seu modelo.
Isso é mais útil na chave-primária de um objeto quando este objeto “estende” um outro objeto de alguma maneira.
\nA OneToOneField requer um argumento posicional: a classe com a qual o modelo é relacionado.
Por exemplo, se você estiver construindo um banco de dados de “places”, você pode construir coisas bem padrão tal como endereços, número de telefone, etc. no banco de dados. Então se quiser construir um banco de dados de restaurantes baseado nos lugares, ao invés de repetir a si mesmo e replicar aqueles campos no modelo Restaurant, você pode fazer Restaurant ter um OneToOneField para Place ( porque um restaurante “é um” lugar; de fato, para lidar com isso você poderia tipicamente usar herança, a qual envolve uma relação um-para-um implícita).
Assim como a ForeignKey, um relacionamento recursivo pode ser definido e referencia a modelos ainda não definidos pode ser feita.
Os campos OneToOneField também aceitam um argumento opcional parent_link.
Classes OneToOneField usados para automaticamente se tornar a chave-primária de um modelo. Isso não e mais verdade (embora você possa passar manualmente no argumento attr:~django.db.models.Field.primary_key se quiser). Então, agora é possível ter múltiplos campos de tipos OneToOneField em um único modelo.
É perfeitamente OK relacionar um modelo de uma aplicação com outro. Para fazer isso, importe o modelo relacionado baseado no início do arquivo onde seu modelo está definido. Então, apenas referencie ao outra classe de modelo onde precisar. Por exemplo:
\nfrom django.db import models\nfrom geography.models import ZipCode\n\nclass Restaurant(models.Model):\n # ...\n zip_code = models.ForeignKey(\n ZipCode,\n on_delete=models.SET_NULL,\n blank=True,\n null=True,\n )\nO Django coloca somente duas restrições sobre os nomes dos campos de modelo:
\nUm nome de campo não pode ser uma palavra-reservada do Python, porque isso poderia resultar em um erro de syntax Python. Por exemplo:
\nclass Example(models.Model):\n pass = models.IntegerField() # 'pass' is a reserved word!\nUm nome de campo não pode conter mais de um “underscore” em uma linha, devido a maneira como a sintaxe dos filtros de pesquisa do Django funcionam.
\nclass Example(models.Model):\n foo__bar = models.IntegerField() # 'foo__bar' has two underscores!\nEssas limitações podem ser contornadas, embora, porque seu nome de campo não tem que combinar necessariamente com os nomes de colunas dos banco de dados. Veja a opção db_column.
Palavras-reservadas SQL, tal como join, where ou select, são permitidas como um nome de campos de modelo, porque o Django escapa todos os nomes de colunas e tabelas do banco de dados em cada consulta SQL. Ele usa a sintaxe citada do “engine” do seu banco de dados em particular.
Se um dos campos de modelo existentes não pode ser usado para atender seus propósitos, ou se você deseja tirar vantagem de algum tipo de coluna de banco de dados menos comum, você pode criar sua própria classe de campo. Uma cobertura completa de criar seus próprios campos é fornecido em Escrevendo campos personalizados de modelos..
\nMetaLink para este cabeçalho#Dê ao seu modelo meta-dados usando uma class Meta interna, como segue:
from django.db import models\n\nclass Ox(models.Model):\n horn_length = models.IntegerField()\n\n class Meta:\n ordering = ["horn_length"]\n verbose_name_plural = "oxen"\nMeta-dado de modelo é “qualquer coisa que não é um campo”, assim como opções de ordenamento (ordering), nome da tabela do banco de dados (db_table), ou nomes legíveis plural e singular (verbose_name and verbose_name_plural). Nenhum é requierido, e adicionar class Meta ao seu modelo é completamente opcional.
Uma lista completa de todos as opções Meta possíveis pode ser encontrada na referência de opções de modelo.
objetosO atributo mais importante de uma classe de modelo é o Manager. Ele é a interface através da qual o operações de consultas no banco de dados são fornecidas aos modelos do Django e usadas para retornar instâncias de modelos do banco de dados. Se nenhum Manager personalizado é definido, o nome padrão é objects. Os “managers” somente são acessíveis através de classes de modelos, não por instâncias de de modelos.
Defina métodos personalizados em um modelo para adicionar funcionalidade de “nível de linha” personalizado a seus objetos. Enquanto que os métodos Manager são para coisas para “toda a tabela”, métodos de modelos devem agir sobre uma intância de modelo em particular.
Esta é uma técnica valiosa para manter a lógica de negócios em um único lugar – o modelo.
\nPor exemplo, este modelo tem alguns poucos métodos personalizados:
\nfrom django.db import models\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n birth_date = models.DateField()\n\n def baby_boomer_status(self):\n "Returns the person's baby-boomer status."\n import datetime\n if self.birth_date < datetime.date(1945, 8, 1):\n return "Pre-boomer"\n elif self.birth_date < datetime.date(1965, 1, 1):\n return "Baby boomer"\n else:\n return "Post-boomer"\n\n def _get_full_name(self):\n "Returns the person's full name."\n return '%s %s' % (self.first_name, self.last_name)\n full_name = property(_get_full_name)\nO último métodos neste exemplo é uma propriedade.
\nA refrência de instância de modelo tem um lista completa de métodos automaticamente dados a cada modelos. Você pode sobrescrever a maioria deles – veja sobrescrevendo métodos pré-definidos de modelo, abaixo – mas existem alguns que você irá quase sempre querer definir:
\n__str__() (Python 3)Um “método mágico” que retorna a “representação” em unicode de qualquer objeto. Este é o que o Python e o Django irão usar onde uma instância de modelo precisar ser mostrada como uma string. Mais notávelmente, isso acontece quando você mostra umobjeto em um console interativo ou no “admin”.
\nVocê sempre irá querer definir este método; o padrão em geral não ajuda muito.
\n__unicode__() (Python 2)O equivalente para Python 2 de __str__().
get_absolute_url()Este dia ao Django como calcular a URL de um objeto. O Django usa isso na sua interface do “admin” e a qualquer momento que ele precisa descobrir a URL de um objeto.
\nQualquer objeto que tem um URL que o identifica unicamente deve definir este método.
\nExiste um outro conjunto de métodos de modelos que encapsulam vários comportamentos ligados ao banco de dados que você irá querer personalizar. EM particu;ar você irá querer muitas vezes alterar a maneira que o save() e delete() funcionam.
Você é livre para sobrescrever estes métodos (e qualquer outro método de modelo) para alterar o comportamento.
\nUm caso de uso clássico para sobrescrever métodos embutidos é se você quiser que algo aconteça quando salvar um objeto. Por exemplo (veja save() para a documentaçao dos parâmetros que ele aceita):
from django.db import models\n\nclass Blog(models.Model):\n name = models.CharField(max_length=100)\n tagline = models.TextField()\n\n def save(self, *args, **kwargs):\n do_something()\n super(Blog, self).save(*args, **kwargs) # Call the "real" save() method.\n do_something_else()\nVocê pode também evitar salvar:
\nfrom django.db import models\n\nclass Blog(models.Model):\n name = models.CharField(max_length=100)\n tagline = models.TextField()\n\n def save(self, *args, **kwargs):\n if self.name == "Yoko Ono's blog":\n return # Yoko shall never have her own blog!\n else:\n super(Blog, self).save(*args, **kwargs) # Call the "real" save() method.\nÉ importante lembrar de chamar o método da super-classe – que é o porque do ``super(Blog, self).save(*args, **kwargs)` – para ter certeza que o objeto ainda será persistido no banco de dados. Se você esquecer de chamar o método da super-classe, o comportamento padrão não acontecerá e nunca chegará ao banco de dados.
\nÉ importante também que você passe os argumentos que podem ser passados para o método do modelo que é o que as partes *args, **kwargs fazem. O Django irá, de vez enquando, estender as capacidades dos métodos embutidos de modelo, adicionando novos argumento. Se você usar *args, **kwargs nas definições de seus métodos, você está garantido que seu código ira automaticamente da suporte a estes argumentos quando forem adicionados.
Um outro padrão comum é escrever comandos SQL personalizados em métodos de modelos e métodos no nível do módulo. Para mais detalhes sobre usar SQL puro, veja a documentação no usando SQL puro.
\nA herança de modelo no Django funciona quase idêntico a maneira que herança de classes normais no Python, mas o básico do início da página ainda deve ser seguido. Isso significa que c classe base deve ser uma subclasse de django.db.models.Model.
A única decisão que você tem tomar é se você quer que os modelos pais sejam modelos por eles mesmos (com suas próprias tabelas de banco de dados), ou se os modelos parentes são somente para manter informações comuns que somente serão vistas através de seus modelos filhos.
\nExistem três estilos de herança que possíveis em Django.
\nMuitas vezes, você quer somente usar uma classe pai para manter informação que você não quer ter que escrever para cada modelo filho. Essa classe nunca será usada isoladamente, então o que você quer é uma Classes abstratas base
Se você estiver herdando um modelo existente (talvez algo de uma outra aplicação inteira) e quer que cada modelo tenha sua própria tabela de banco de dados, o Herança de múltiplas tabelas é o caminho.
Finalmente, se você quer modificar o comportamento no nível do Python de um modelo, sem mudar os campos do modelo de nenhuma maneira, você pode usar os Modelos Proxy.
Classes abstratas base são úteis quando você quer colocar alguma informação comum em vários outros modelos. Você escreve sua classe base e coloca abstract=True na classe in the Meta. Este modelo não será então usado para criar nenhuma tabela de banco de dados. Ao invés disso, quando é usado como classe base para outros modelos, seus campos serão adicionados àqueles das classes filhas. É um erro ter campos de classes abstratas base com o mesmo nome daqueles da classe filha (e o Django irá emitir uma exceção).
Um exemplo:
\nfrom django.db import models\n\nclass CommonInfo(models.Model):\n name = models.CharField(max_length=100)\n age = models.PositiveIntegerField()\n\n class Meta:\n abstract = True\n\nclass Student(CommonInfo):\n home_group = models.CharField(max_length=5)\nO modelo Student terá três campos: name, age e home_group. O modelo CommonInfo não pode ser usado como um modelo normal do Django, já que é uma classe abstrata base. Ele não gera uma tabela de banco de dados nem tem um “manager”, e não pode ser instânciado ou salvo diretamente.
Em muitos casos, este tipo de herança de modelo será exatamente o que quer. Isso lhe fornece uma maneira de fatorar informações comuns ao nível do Python, enquanto cainda cria somente uma tabela de banco de dados para cada modelo filho no nível banco de dados.
\nMetaLink para este cabeçalho#QUando um modelo abstrato básico é criado, o Django com que qualquer classe Meta interna que você declare na classe base fique disponível como um atributo. Se a classe filha não declare sua própria classe Meta , ela irá herdar as Meta da pai. Se a filho quer estender a classe Meta da pai, ele pode herdá-la. Por exemplo:
\nfrom django.db import models\n\nclass CommonInfo(models.Model):\n # ...\n class Meta:\n abstract = True\n ordering = ['name']\n\nclass Student(CommonInfo):\n # ...\n class Meta(CommonInfo.Meta):\n db_table = 'student_info'\nO Django faz um ajuste a classe Meta de uma classe abstrata base: antes de instalar o atributo Meta, ele definie abstract=False`. Isso significa que filhos de uma classe abstrata base não se tornam automaticamente uma classe abstrata. Claro, você pode fazer uma classe abstrata que herda de outra abstrata. Você só precisa se lembrar a cada vez de explicitamente definir abstract=True.
Alguns atributos não farão sentido incluir na classe Meta de uma classe abstrata base. Por exemplo, incluir db_table poderia siginificar que todas as classes filhos (aquelas que não especificarem seus próprios Meta) poderiam usar a mesma tabela, o que é quase certo que não é o que você quer.
O segundo tipo de heraná de modelo que o Django suporta é quando cada modelo na hierarquia é um modelo completo. Cada modelo corresponder a sua própria tabele de banco de dados e pode ser consultado e criado individualmente. A herança de relacionamento introduz conexões entre a classe filho e cada um de seus parentes (através de um OneToOneField criado automaticamente). Por exemplo:
from django.db import models\n\nclass Place(models.Model):\n name = models.CharField(max_length=50)\n address = models.CharField(max_length=80)\n\nclass Restaurant(Place):\n serves_hot_dogs = models.BooleanField(default=False)\n serves_pizza = models.BooleanField(default=False)\nTodos os campos de Place``estarão disponíveis no ``Restaurant, embora os dados residirão em tabelas diferentes dos banco de dados. Então estes são ambos possíveis.
>>> Place.objects.filter(name="Bob's Cafe")\n>>> Restaurant.objects.filter(name="Bob's Cafe")\nSe você tive um Place que é também um Restaurant, você pode ir do objeto Place ao objeto Restaurant usando a versão em minúsculo do nome do modelo:
>>> p = Place.objects.get(id=12)\n# If p is a Restaurant object, this will give the child class:\n>>> p.restaurant\n<Restaurant: ...>\nTodavia, se p no exemplo acima não é um Restaurant (ele foi criado diretamente como um objeto Place ou era um pai de uma alguma outra classe), referenciar p.restaurant poderia emitir uma exceção Restaurante.DoeNotExist.
Meta e herança de tabelas múltiplasLink para este cabeçalho#Na situação de herança de multi-tabelas , faz sentido para uma classe filho herdar de seu pai a classe Meta. Todas as opções Meta já foram aplicadas a classe pai aplicar novamente poderia normalmente levar a um comprtamento contraditório (isso em contrate com o caso da classe abstrata base, onde a classe base não existe por sí só).
\nEntão um modelo filho não tem acesso a classe Meta do seu pai. Porém, existem alguns poucos casos onde o filho herda comportamento do pai: se o filho não especifica um atributo ordering ou um atributo get_latest_by, ele herdará isso dos seu pai.
Se o pai tem um ordenação e você não quer que o filho tenha qualquer ordem natural, você pode explicitamente desabilitar isso:
\nclass ChildModel(ParentModel):\n # ...\n class Meta:\n # Remove parent's ordering effect\n ordering = []\nPorque herança de multi-tabelas usa um OneToOneField implícita para relacionar o filho com o pai, é possível mover do pai para o filho, como no exemplo acima. Porém, usa-se o nome que é padrão value do related_name para ForeignKey e relções ManyToManyField. Se você está colocando estes tipos de relações em uma subclasse do modelo pai, você deve especificar o atributo related_name em cada campo deste. Se você esquecer, o Django irá emitir um erro de validação.
Por exemplo, usando novamente a classe Place acima, vamos criar outra subclasse com um ManyToManyField:
class Supplier(Place):\n customers = models.ManyToManyField(Place)\nIsso resulta no erro:
\nReverse query name for 'Supplier.customers' clashes with reverse query\nname for 'Supplier.place_ptr'.\n\nHINT: Add or change a related_name argument to the definition for\n'Supplier.customers' or 'Supplier.place_ptr'.\nAdicionando related_name ao campo customers como segue poderia resolver o erro: models.ManyToManyField(Place, related_name='provider').
Como mencionado, o Django criará automaicamente uma relação OneToOneField para sua classe filho devolta para quaisquer modelos não abstratos. Se quiser controlar o nome do atributo de relacionamento devolta para o pai, você pode criar seu próprio OneToOneField e definir parent_link=True para indicar que seu campo é a conexão de reotorno com a classe pai.
Quando se usa herança de tabelas multiplas, uma nova tabela de banco de dados é criada para cada subclasse do modelo. Este é o comportamento desejável, já que a subclasse precisa de um lugar para armazenar qualquer campo de dado adicional que não esteja presente na classe base. As vezes, entretanto, você quer somente mudar o comportamento Python do modelo – talvez para alterar o “manager” padrão do modelo, ou adicionar um método novo.
\nÉ para isso que serve o modelo “proxy”: criar um proxy para o modelo original. Você pode criar, deletar e editar instâncias do modelo “proxy” e todas os dados serão salvos como se você estivesse usando o modelo original (não “proxy”). A diferença, é que você pode alterar coisas como a ordenação padrão do modelo ou o “manager” padrão no “proxy”, sem ter que alterar o original.
\nModelos “Proxy” são declarados como os modelos normais. Você diz ao Django que este é um modelo “proxy” definindo o atributo proxy na classe Meta como True.
Por exemplo, suponha que queira adicionar um método ao modelo Person. Você pode fazê-lo assim:
from django.db import models\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=30)\n last_name = models.CharField(max_length=30)\n\nclass MyPerson(Person):\n class Meta:\n proxy = True\n\n def do_something(self):\n # ...\n pass\nA classe MyPerson opera na mesma tabela que sua classe pai Person. Em particular, qualquer nova instância de Person irá também ser acessível através de MyPerson, e vice-versa:
>>> p = Person.objects.create(first_name="foobar")\n>>> MyPerson.objects.get(first_name="foobar")\n<MyPerson: foobar>\nVocê pode também usar um modelo “proxy” para definir um ordenação padrão diferente em um modelo. Talvez você não queira sempre ordenar o modelo Person`, mas regularmente ordenar pelo atributo ``last_name quando usar o “proxy”. Isso é fácil:
class OrderedPerson(Person):\n class Meta:\n ordering = ["last_name"]\n proxy = True\nAgora consultas normais ao Person serão não ordenadas e consultas ao OrderedPerson serão ordenadas pelo last_name.
QuerySets ainda retornam o modelo que foi requisitadoLink para este cabeçalho#Não te uma maneira do Django retornar, vamos dizer, um objeto MyPerson quando consultar por objetos Person. Uma consulta em objetos Person irá retornar aquele tipo de objetos. O ponto de objetos “proxy” é que o código que está no Person original irá usar este código e seu próprio código pode usar as estensões que foram incluídas (que nenhum outro código depende de nenhuma forma). Esta não é uma maneira de substituir o modelo Person (ou nenhum outro) em nenhum lugar com alguma coisa criada por você mesmo.
Um modelo “proxy” deve herdar de exatamente um modelo não abstrato. Você não pode herdae de múltimplos modelos não abstratos já que o modelo “proxy” não fornece qualquer conexão entre os registros de diferentes tabelas do banco de dados. Um modelo “proxy” pode herdar de qualquer número de classes abstratas de modelos, desde que não definam nenhum campo de modelo.
\nSe você não especificar um “manager” do modelo no modelo “proxy”, ele herda o “manager” de seu modelo pai. Se você definir um “manager” no modelo “proxy”, este será o padrão, embora qualquer “manager” definido nas classes pai ainda estarão disponíveis.
\nContinuando nosso exemplo acima, você pode mudar o “manager” padrão usado quando você fizer uma consulta ao modelo Person assim:
from django.db import models\n\nclass NewManager(models.Manager):\n # ...\n pass\n\nclass MyPerson(Person):\n objects = NewManager()\n\n class Meta:\n proxy = True\nSe você quiser adicionar um novo “manager” ao “Proxy”, sem substituir o padrão existente, você pode usar as técnicas descritas na documentação “manager” personalizado : crie uma classe base contendo os novos “managers” e herde esta depois da classe base primária:
\n# Create an abstract class for the new manager.\nclass ExtraManagers(models.Model):\n secondary = NewManager()\n\n class Meta:\n abstract = True\n\nclass MyPerson(Person, ExtraManagers):\n class Meta:\n proxy = True\nVocê provavelmente não precisa fazer isso muitas vezes, mas, quando precisar, é possível.
\nHerança de modelo “proxy” talvez se pareça com criar um modelo não gerenciado, usando o atributo managed na classe Meta do modelo. As duas alternativas não são necessariamente a mesma coisa e vale a pena considerar qual delas você deveria usar.
Uma diferença é que você pode (e, de fato deve, a menos que você queira um modelo vazio) especificar campos de modelos no modelo com Meta.managed=False. Você poderia, definir com cuidado o Meta.db_table para que crie um modelo não gerenciado que seja similar ao modelo existente e adicionar métodos Python nele. Porém, isso seria muito repetitivo e frágil já que precisaria manter ambas as cópias sincronizadas se fizer alguma mudança.
A outra diferença que é ainda mais importante para modelos “proxy”, é como os “managers” do modelo são manipulados. Modelos do tipo “proxy” tendem a se comportar exatamente como o modelo do qual é “proxy”. QUer dizer que herdam o “manager” do modelo pai, incluindo o “manager” padrão. Em um caso normal de herança de de modelos de tabelas múltiplas, filhos não herdam os “managers” dos seus pais já que “managers” personalizados nem sempre são apropriados quando envolve campos extras. A documentação de referência de “manager” tem mais detalhes sobre este último caso.
\nQuando estas duas características foram implementadas, houveram tentativas de se unificá-las em uma única opção. Descobriu-se que a interações com herança, em geral, e particularmente com “managers”, fazem a API muito complexa e potencialmente difícil de entender e usar. Descobriu-se que duas opções eram necessárias emqualquer caso, então a separação corrente veio a tona.
\nEntão, as regras gerais são:
\nSe você esta espelhando um modelo existente ou uma tabela de banco de dados e nao quer todas as colunas originarias do banco de dados, use Meta.managed=False. Esta opção é normalmente útil para modelos “views” e tabelas de bancos de dados que não estão sob o controle do Django.
Se voc^está querendo alterar o modelo somente quanto seu comportamento Python, más manter todos os mesmos campos como no original, use Meta.proxy=True. Estas defini as coisas tal que o modelo “proxy” é uma cópia exata da estrutura de armazenamento do modelo original quando o dado são salvos.
Tal como é fazer uma subclasse em Python, é possível para um modelo Django herdar múltiplos modelos pai. Tenha em mente que as regras de resolução de nomes Python se aplicam. A primeira classe base que um nome em particular (e.g. Meta) aparece será a classe usada; por exemplo, isso significa que se múltimplos pais contém uma classe Meta, somente a primeira é que será usada, e todas as outras ignoradas.
\nGeralmente, você não vai precisar herdar de múltiplos pais. O principal caso onde isso é útil é para classes “mix-in”: adicionar um campo extra em particular ou método para ada classe que herda o “mix-in”. Tente manter sua hierarquia de herança tão simples e direta quanto possível, assim você não tem que lutar para descobrir de onde está vindo uma parte particuar da informação.
\nPerceba que herdar de múltimplos modelos que tem em comum um campo ìd` como chave-primária irá emitir um erro. Para usar heraná múltipla de maneira correta, você pode usar explicitamente a AutoField no modelo base:
class Article(models.Model):\n article_id = models.AutoField(primary_key=True)\n ...\n\nclass Book(models.Model):\n book_id = models.AutoField(primary_key=True)\n ...\n\nclass BookReview(Book, Article):\n pass\nOu use um acestral comum para manter a AutoField:
class Piece(models.Model):\n pass\n\nclass Article(Piece):\n ...\n\nclass Book(Piece):\n ...\n\nclass BookReview(Book, Article):\n pass\nEm uma herança de classe normal em Python, é permitido a um filho que sobrescreva qualquer atributo de uma classe pai. No Django, isso não é permitido fazer para atributos que são instâncias da Field (pelo menos, não no momento). Se uma classe base tem um campo chamado author, você não pode criar outro campo de modelo chamado author em qualquer classe que herde a classe base.
Sobrescrever campos em um modelo pai leva a dificuldades em áreas como a inicialização de novas instâncias (especificar qual campo está sendo inicializado no Model.__init__) e serialização. Estas são características que classes Python normais não tem que lidar do mesmo modo, isso quer dizer que a diferença entre herança de modelos Django e herança de classes Python não são arbitrárias.
A restrição somente se aplica a atributos os quais são instâncias de Field. Atributos normais de Python podem ser sobrescritos se quiser. Isos também só se aplica para os nomes de atributos com o Python os vê. Se você está manualmente especificando o nome da coluna do banco de dados, você pode ter o mesmo nome de coluna aparecendo em ambos, um filho e em um modelo ancestral para heraná de múltiplas tabelas (elas são solunas em duas diferentes tabelas de banco de dados).
O Django irá emitir uma FieldError se você sobrescrever qualquer campo de modelo de qualquer modelo ancestral.
The manage.py startapp command creates an application\nstructure that includes a models.py file. If you have many models,\norganizing them in separate files may be useful.
To do so, create a models package. Remove models.py and create a\nmyapp/models/ directory with an __init__.py file and the files to\nstore your models. You must import the models in the __init__.py file.
For example, if you had organic.py and synthetic.py in the models\ndirectory:
myapp/models/__init__.pyfrom .organic import Person\nfrom .synthetic import Robot\nExplicitly importing each model rather than using from .models import *\nhas the advantages of not cluttering the namespace, making code more readable,\nand keeping code analysis tools useful.