Ativando modelos
Aquele pequeno trecho de código do modelo dá ao Django muita informação. Com ele, o Django é capaz de:
- Criar um esquema de banco de dados (instruções
CREATE TABLE) para este aplicativo.
- Criar uma API Python de acesso ao banco de dados para acessar objetos
Question e Choice.
Mas primeiro precisamos dizer ao nosso projeto que o aplicativo polls está instalado.
Os aplicativos Django são "plugáveis": você pode usar um aplicativo em vários projetos e pode distribuir aplicativos, porque eles não precisam estar vinculados a uma determinada instalação do Django.
Para incluir o aplicativo em nosso projeto, precisamos adicionar uma referência à sua classe de configuração na configuração INSTALLED_APPS. A classe PollsConfig está no arquivo polls/apps.py, então seu caminho pontilhado é 'polls.apps.PollsConfig'. Edite o arquivo mysite/settings.py e adicione esse caminho pontilhado à configuração INSTALLED_APPS. Ele ficará assim:
INSTALLED_APPS = [
"polls.apps.PollsConfig",
"django.contrib.admin",
"django.contrib.auth",
"django.contrib.contenttypes",
"django.contrib.sessions",
"django.contrib.messages",
"django.contrib.staticfiles",
]
Agora o Django sabe para incluir o aplicativo polls. Vamos executar outro comando:
python manage.py makemigrations polls
Você deve ver algo semelhante ao seguinte:
Migrations for 'polls':
polls/migrations/0001_initial.py
- Create model Question
- Create model Choice
Ao executar makemigrations, você está dizendo ao Django que fez algumas alterações em seus modelos (neste caso, você fez novos) e que gostaria que as alterações fossem armazenadas como uma migration (migração).
As migrações são como o Django armazena as alterações em seus modelos (e, portanto, em seu esquema de banco de dados) - elas são arquivos em disco. Você pode ler a migração para seu novo modelo, se quiser; é o arquivo polls/migrations/0001_initial.py. Não se preocupe, não se espera que você as leia toda vez que o Django fizer uma, mas elas são projetadas para serem editáveis por humanos, caso você queira ajustar manualmente como o Django altera as coisas.
Existe um comando que executará as migrações para você e gerenciará seu esquema de banco de dados automaticamente - isso é chamado de migrate, e chegaremos a ele em um momento - mas primeiro, vamos ver qual SQL essa migração executaria. O comando sqlmigrate recebe nomes de migração e retorna seu SQL:
python manage.py sqlmigrate polls 0001
Você deve ver algo semelhante ao seguinte (reformatamos para legibilidade):
BEGIN;
--
-- Create model Question
--
CREATE TABLE "polls_question" (
"id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
"question_text" varchar(200) NOT NULL,
"pub_date" timestamp with time zone NOT NULL
);
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
"id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
"choice_text" varchar(200) NOT NULL,
"votes" integer NOT NULL,
"question_id" bigint NOT NULL
);
ALTER TABLE "polls_choice"
ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"
FOREIGN KEY ("question_id")
REFERENCES "polls_question" ("id")
DEFERRABLE INITIALLY DEFERRED;
CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");
COMMIT;
Observe o seguinte:
- A saída exata variará dependendo do banco de dados que você está usando. O exemplo acima é gerado para PostgreSQL.
- Os nomes das tabelas são gerados automaticamente combinando o nome do aplicativo (
polls) e o nome do modelo em letras minúsculas -- question e choice. (Você pode substituir esse comportamento.)
- Chaves primárias (IDs) são adicionadas automaticamente. (Você também pode substituir isso.)
- Por convenção, o Django anexa
"_id" ao nome do campo de chave estrangeira. (Sim, você também pode substituir isso.)
- O relacionamento de chave estrangeira é explicitado por uma restrição
FOREIGN KEY. Não se preocupe com as partes DEFERRABLE; ele está dizendo ao PostgreSQL para não impor a chave estrangeira até o final da transação.
- Ele é adaptado ao banco de dados que você está usando, então tipos de campo específicos do banco de dados, como
auto_increment (MySQL), bigint PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY (PostgreSQL) ou integer primary key autoincrement (SQLite) são tratados automaticamente para você. O mesmo vale para a citação de nomes de campos -- por exemplo, usando aspas duplas ou aspas simples.
- O comando
sqlmigrate na verdade não executa a migração em seu banco de dados - em vez disso, ele a imprime na tela para que você possa ver qual SQL o Django acha que é necessário. É útil para verificar o que o Django vai fazer ou se você tem administradores de banco de dados que exigem scripts SQL para alterações.
Se você estiver interessado, também pode executar python manage.py check <check>; isso verifica se há algum problema em seu projeto sem fazer migrações ou tocar no banco de dados.
Agora, execute migrate novamente para criar essas tabelas de modelo em seu banco de dados:
python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
Applying polls.0001_initial... OK
O comando migrate pega todas as migrações que não foram aplicadas (o Django acompanha quais são aplicadas usando uma tabela especial em seu banco de dados chamada django_migrations) e as executa em seu banco de dados - essencialmente, sincronizando as alterações que você fez em seus modelos com o esquema no banco de dados.
As migrações são muito poderosas e permitem que você altere seus modelos ao longo do tempo, à medida que você desenvolve seu projeto, sem a necessidade de excluir seu banco de dados ou tabelas e criar novos - ele se especializa em atualizar seu banco de dados ao vivo, sem perder dados. Abordaremos isso com mais profundidade em uma parte posterior do tutorial, mas por enquanto, lembre-se do guia de três etapas para fazer alterações no modelo:
- Altere seus modelos (em
models.py).
- Execute
python manage.py makemigrations <makemigrations> para criar migrações para essas alterações
- Execute
python manage.py migrate <migrate> para aplicar essas alterações ao banco de dados.
A razão pela qual existem comandos separados para fazer e aplicar migrações é porque você confirmará as migrações em seu sistema de controle de versão e as enviará com seu aplicativo; elas não apenas tornam seu desenvolvimento mais fácil, mas também são utilizáveis por outros desenvolvedores e em produção.
Leia a documentação do django-admin </ref/django-admin> para obter informações completas sobre o que o utilitário manage.py pode fazer.
