# Atualizar o banco de dados

A partir de agora existe **um arquivo só** para tudo: **`api/database/schema.sql`**.

Ele serve para as **duas** situações, com o **mesmo comando**:

- **Instalação nova** → cria as 76 tabelas do zero.
- **Servidor em produção, com dados** → **adiciona só o que está faltando**.

> ## 🛡️ Garantia
> O `schema.sql` **não apaga nada**. Não tem `DROP`, nem `TRUNCATE`, nem `DELETE`,
> nem alteração de coluna existente. Ele **só acrescenta**. Pode rodar duas vezes
> seguidas sem problema.

---

## ⚠️ Antes de qualquer coisa: faça backup

Mesmo com a garantia acima. Backup é barato; recuperar dado perdido, não.

1. Abra o **Prompt de Comando**.
2. Rode:

```
cd C:\wamp64\www
api\scripts\db_dump.bat
```

✅ **Deu certo se…** aparecer um arquivo `.sql` novo (com data e hora no nome).

---

## Rodar a atualização

No **Prompt de Comando**:

```
cd C:\wamp64\www
C:\wamp64\bin\mariadb\mariadb11.4.9\bin\mariadb.exe -h 127.0.0.1 -P 3307 -u guilherme -p controle_veiculos < api\database\schema.sql
```

Ele vai pedir a senha do banco. Depois, roda em silêncio (uns segundos).

✅ **Deu certo se…** ele voltar para o prompt **sem mensagem de erro**.
Avisos (`Warning: ... duplicate column name`) são **normais e esperados** — é o
arquivo dizendo *"essa coluna já existe, pulei"*. Não é erro.

---

## Como ele consegue atualizar sem apagar

O arquivo tem 4 seções, e a ordem importa:

| Seção | O que faz |
|---|---|
| **1. Tabelas** | `CREATE TABLE IF NOT EXISTS` — cria a tabela que falta; se já existe, **pula** (não toca nos dados). |
| **2. Colunas** | `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` (707 comandos). **É o pulo do gato** — veja abaixo. |
| **3. Índices** | `ADD INDEX IF NOT EXISTS` (173 comandos). |
| **4. Seeds** | Valores iniciais. **Nunca sobrescrevem** o que você já configurou na tela. |

### Por que a seção 2 é essencial

`CREATE TABLE IF NOT EXISTS` tem uma pegadinha: se a tabela **já existe**, ele pula a
tabela **inteira** — e **não adiciona as colunas novas**. Num banco de produção que
pulou uma atualização, o sistema quebraria com *"Unknown column"*.

A seção 2 resolve: ela tenta adicionar **cada coluna, uma por uma**. Se a coluna já
existe, é ignorada. Se falta, é criada. É isso que faz um banco antigo se "auto-curar".

---

## E os arquivos `migration_*.sql`?

Continuam lá, mas **você não precisa mais deles**. O `schema.sql` já faz tudo o que
eles faziam. Eles ficam como **histórico** (e para quem quiser aplicar uma mudança
isolada).

---

## Deu problema?

**"Duplicate column name" / "Duplicate key name"**
Não é erro — é **aviso**. Significa "já existe, pulei". É o comportamento esperado.

**"Duplicate entry '...' for key '...'"** (num índice ÚNICO)
Aqui é dado, não schema: a base tem uma **duplicata** que viola uma regra de
unicidade nova. Encontre e remova a duplicata, e rode o arquivo de novo (ele é
idempotente — o que já passou não é refeito). **Nada foi apagado.**

**"Unknown column" depois de rodar**
O arquivo não chegou até o fim (algum erro antes). Role a saída para cima, ache o
primeiro **ERROR** (não os warnings) e resolva. Depois rode de novo.

**Rodei duas vezes sem querer**
Sem problema. O arquivo é idempotente: a segunda passada não faz nada.

---

## ⚠️ Para quem for mexer no arquivo

**Nunca** regenere o `schema.sql` com `mysqldump` no modo padrão. O padrão é
`--add-drop-table`, que escreve um `DROP TABLE` antes de cada `CREATE` — e foi
exatamente assim que o `schema.sql` chegou a ter **18 `DROP TABLE`**, incluindo
`pessoa`, `usuario` e `historico_passagem`. Rodá-lo em produção teria apagado tudo.

O `db_estrutura.bat` já foi corrigido para usar `--skip-add-drop-table`, e o
`static_check.php` (**check 12**) agora **falha** se algum `DROP`/`TRUNCATE`/`DELETE`
voltar a aparecer no `schema.sql`.