Configurando o banco de dados a ser utilizado na app:
Para tal, acessar o arquivo enquetes/settings.py. Este arquivo armazena diversas configuração do Django.
Por padrão, o Django usa o SQLite. Servirá para os testes. Futuramente pense em um banco de dados mais escalável como o MySQL ou PostgreSQL.
Veja no settings.py a referência ao SQLite:
# Database
# https://docs.djangoproject.com/en/2.0/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), # caminho completo + nome do arquivo
}
}
Aproveite para alterar o TIME_ZONE para o seu fuso horário, dentro do settings.py:
TIME_ZONE = 'America/Sao_Paulo'
Veja também a configuração do INSTALLED_APPS. Lá estão os nomes de todas as aplicações Django ativas para essa instância do Django. Aplicações podem ser usadas em múltiplos projetos, e você pode empacotá-las e distribuí-las para uso por outros em seus projetos.
Por padrão, o INSTALLED_APPS contém as seguintes aplicações, que vêm com o Django:
django.contrib.admin – O administração: interface do Django.
django.contrib.auth – Um sistema de autenticação.
django.contrib.contenttypes – Um framework para tipos de conteúdo.
django.contrib.sessions – Um framework de sessão.
django.contrib.messages – Um framework de envio de mensagem.
django.contrib.staticfiles – Um framework para gerenciamento de arquivos estáticos.
Estas aplicações fazem uso de pelo menos uma tabela no banco de dados, assim sendo, precisamos criar as tabelas no banco de dados antes que possamos utilizá-las. Para tal execute os comandos:
python manage.py makemigrations
python manage.py migrate
Obs.: Observando o INSTALLED_APPS, ass aplicações padrão são incluídas para casos comuns, mas nem sempre precisamos de todas. Se não precisa de alguma, pode comentar ou deletar a(s) linha(s) apropriada(s) do INSTALLED_APPS antes de rodar o migrate. O comando migrate irá executar as migrações apenas para as aplicações que estiverem no INSTALLED_APPS.
--------------------------------------------------------------------
Criando modelos:
Modelos são basicamente o layout do banco de dados, com metadados adicionais.
Nesta app de enquete, criaremos 2 modelos: Questao e Escolha:
Uma Questao tem uma pergunta e uma data de publicação.
Uma Escolha tem dois campos: o texto da escolha e um totalizador de votos.
Cada Escolha é associada a uma Questao.
Esses conceitos são representados por classes Python. Abra arquivo votacao/models.py e codifique:
from django.db import models
class Questao(models.Model):
texto_questao = models.CharField(max_length=200)
data_pub = models.DateTimeField('Data de Publicação', null=True)
class Escolha(models.Model):
questao = models.ForeignKey(Questao, on_delete=models.CASCADE)
texto_escolha = models.CharField(max_length=200)
votos = models.IntegerField(default=0)
--------------------------------------------------------------------
Observações importantes:
Tanto a Classe Questao quanto a Classe Escolha são classes derivadas de models.Model.
Cada model possui um número de atributos de classe, que representará campos de banco de dados.
Cada campo é representado por uma instância da classe Field. O nome de cada instância Field (ex.: texto_questao, data_pub, etc.) é o nome do campo, para ser utilizado na app Python e será o nome da coluna do banco de dados.
Podemos definir um nome legível de apresentação do campo dentro do Django. Se não for informado, o nome do campo é default para sua exibição.
Algumas classes de Field possuem elementos obrigatórios. O CharField, por exemplo, requer que você informe a ele um max_length que é usado não apenas no esquema do banco de dados, mas também na validação. Um Field pode ter vários argumentos opcionais; neste caso, nos definimos default o valor do campo votos para 0.
No campo questao, uma relação foi criada, usando ForeignKey. Isto especifica ao Django que cada Escolha está relacionada a uma única Questao.
Relacionamento 1:n - 1 Questao pode ter 1 ou mais Escolha"
O Django suporta todos os relacionamentos comuns de um banco de dados: muitos-para-um, muitos-para-muitos e um-para-um.
--------------------------------------------------------------------
Ativando modelos:
Com a parte model da aplicação, o Django é capaz de:
-Criar um esquema de banco de dados para a aplicação (SQL).
-Criar uma API de acesso a banco de dados para acessar objetos de classes.
Inicialmente, informe ao projeto que a aplicação votacao está instalada. Para incluir uma app ao projeto, precisamos adicionar a referência à classe de configuração da aplicação na definição do INSTALLED_APPS.
A classe VotacaoConfig está no arquivo :file:`votacao/apps.py`, então o caminho pontuado é 'votacao.apps.VotacaoConfig'. Edite o arquivo enquetes/settings.py e adicione aquele caminho com notação de ponto a definição do INSTALLED_APPS. Ficará parecido como aqui:
mysite/settings.py
INSTALLED_APPS = [
'votacao.apps.VotacaoConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]
Agora o Django sabe que deve incluir a aplicação votacao.
Execute o comando:
python manage.py makemigrations votacao
Obs.: Podemos usar uma app Django em múltiplos projetos, e você pode distribuir aplicações, porque elas não precisam ser atreladas a uma determinada instalação do Django.
Ao executar makemigrations, você informa ao Django que foram feitas mudanças em seus modelos e gostaria que as alterações sejam armazenadas como uma migração.
As migrações, por sua vez, são como o Django armazena as alterações nos seus modelos (e, portanto, seu esquema de banco de dados), são apenas arquivos. É possível ler a migração para o novo modelo, acessando o diretório migrations dentro de votacao. Podem ser editados, caso necessite.
Depois, execute o comando migrate para rodar as migrações e gerenciar o esquema de banco de dados automaticamente.
-------------------------------------------------------------------- Obs.: Podemos ver qual SQL uma determinada migração vai aplicar. Execute o comando:
python manage.py sqlmigrate votacao 0001
SQL gerado:
BEGIN;
--
-- Create model Escolha
--
CREATE TABLE "votacao_escolha" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "texto_escolha" varchar(200) NOT NULL, "votos" integer NOT NULL);
--
-- Create model Questao
--
CREATE TABLE "votacao_questao" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "texto_questao" varchar(200) NOT NULL, "data_pub" datetime NOT NULL);
--
-- Add field questao to escolha
--
ALTER TABLE "votacao_escolha" RENAME TO "votacao_escolha__old";
CREATE TABLE "votacao_escolha" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "texto_escolha" varchar(200) NOT NULL, "votos" integer NOT NULL, "questao_id" integer NOT NULL REFERENCES "votacao_questao" ("id") DEFERRABLE INITIALLY DEFERRED);
INSERT INTO "votacao_escolha" ("id", "texto_escolha", "votos", "questao_id") SELECT "id", "texto_escolha", "votos", NULL FROM "votacao_escolha__old";
DROP TABLE "votacao_escolha__old";
CREATE INDEX "votacao_escolha_questao_id_1b0558bc" ON "votacao_escolha" ("questao_id");
COMMIT;
--------------------------------------------------------------------
O SQL gerado vai variar de acordo com o banco de dados que está sendo utilizado.Os nomes das tabelas são gerados automaticamente combinando o nome da aplicação (votacao) e o nome em minúsculas do model – questao e escolha. Isto pode ser alterado.
Chaves primárias (IDs) são adicionadas automaticamente. Isto pode ser alterado.
Por convenção, o Django adiciona "_id" ao nome do campo de uma chave estrangeira. Isto pode ser alterado.
O relacionamento da chave estrangeira é feito explicitamente por uma instrução FOREIGN KEY. O comportamento do código é atrelado ao banco de dados em uso. O mesmo ocorre com as aspas dos nomes de campos, usando aspas duplas ou aspas simples.
Observe que o comando sqlmigrate não aplica o SQL no banco de dados, apenas o exibe na tela para que saiba qual SQL o Django acha que é necessário. Isto pode ser útil se precisar verificar o que Django vai fazer ou se tem administradores de bancos de dados que necessitam dos scripts SQL para mudanças.
Se tiver interesse, pode executar o comando python manage.py check; Ele checa por problemas no seu projeto sem criar migrations ou tocar seu banco de dados.
Então, agora execute o comando migrate novamente para criar essas tabelas dos modelos no banco de dados:
python manage.py migrate
O comando migrate pega todas as migrações que ainda não foram aplicadas (Django rastreia quais foram aplicadas usando uma tabela especial em seu banco de dados chamada django_migrations) e aplica elas contra o banco de dados - essencialmente, sincronizando as alterações feitas aos seus modelos com o esquema no banco de dados.
Migrações são muito poderosas e permitem que você altere seus modelos ao longo do tempo, à medida que desenvolve o seu projeto, sem a necessidade de remover o seu banco de dados ou tabelas e criar de novo - ele é especializado em atualizar seu banco de dados ao vivo, sem perda de dados.
-------------------------------------------------------------------- Resumindo, 3 passos básicos para fazer mudanças nos modelos:
1-Mude seus modelos (em models.py).
2-Execute python manage.py makemigrations para gerar as migrações para suas modificações.
3-Execute python manage.py migrate para aplicar as migrações no banco de dados.
--------------------------------------------------------------------
Nenhum comentário:
Postar um comentário