F03 — Seu primeiro projeto Django: projeto × app, model e migração
Crie o projeto e o app, entenda o papel de cada arquivo, transforme uma classe Python em tabela com makemigrations e migrate, e use o ORM e o painel admin.
Em uma frase: Você monta a cozinha (projeto), abre um departamento (app), escreve a ficha da prateleira (model) e vê o Django construir a tabela no banco (migração). Pergunta guia: O que o Django cria, para que serve cada arquivo e como uma classe Python vira uma tabela no banco?
Slides visuais da lição F03 · NotebookLM
Material multimídia da lição
Raio-X do Django: projeto, app, model e migração
Deck visual para revisar a diferença entre projeto e app, o papel do ORM e o ciclo makemigrations → migrate.
Slides visuais gerados para fixação. O texto pesquisável e os comandos completos permanecem logo abaixo na lição.
Errar uma previsão mostra exatamente onde está a lacuna. Chute mentalmente ou no papel antes de revelar a resposta do professor.
1. No Django, 'projeto' e 'app' são a mesma coisa?
2. Você escreve a classe Produto em models.py e roda direto 'manage.py migrate'. A tabela aparece no banco?
3. Quantas linhas de código você precisa para colocar o cadastro de produtos no painel admin pronto do Django?
1. Cada arquivo do projeto e seu posto no restaurante
Ao rodar startproject minimarket . e startapp catalogo, o Django cria uma estrutura organizada onde cada arquivo tem uma responsabilidade única:
Arquivo
O que faz
Posto no restaurante
manage.py
Recebe ordens (runserver, migrate, test, shell)
Painel de comando da cozinha
minimarket/settings.py
Apps instalados, banco, idioma, DEBUG, SECRET_KEY
Quadro de regras da casa
minimarket/urls.py
Tabela de rotas principais do sistema
Garçom-chefe
catalogo/models.py
Classes Python que definem as tabelas
Ficha de cada prateleira
catalogo/migrations/
Histórico versionado de mudanças no banco
Plantas de reforma da despensa
catalogo/admin.py
Registra models no painel administrativo
Sala do gerente
2. Do Model à Tabela: makemigrations → migrate → sqlmigrate
Repare no uso de DecimalField para dinheiro (nunca FloatField!) e CheckConstraint no banco para impedir estoque negativo mesmo fora do Python:
catalogo/models.py
from django.db import models
class Produto(models.Model):
nome = models.CharField(max_length=120)
preco = models.DecimalField(max_digits=10, decimal_places=2)
estoque = models.PositiveIntegerField(default=0)
class Meta:
constraints = [
models.CheckConstraint(
check=models.Q(estoque__gte=0),
name="estoque_nao_negativo",
)
]
DecimalField — Dinheiro exato em base 10; evita erros de ponto flutuante (0.1 + 0.2 != 0.3)
CheckConstraint — Garante no próprio SQL do banco que estoque nunca fica menor que zero
Quebre de propósito
Esquecer o makemigrations antes do migrate
Experimento: Adicione um campo novo (ex.: ativo = models.BooleanField(default=True)) em Produto e rode direto manage.py migrate.
O que falha: O Django exibe 'No migrations to apply.' e a coluna não é criada. Se você tentar acessar produto.ativo, recebe OperationalError: no such column.
Por que a regra existe: O fluxo tem sempre dois passos: 1) makemigrations (gera a planta da reforma) e 2) migrate (executa a obra no banco).