0008 — pabast_senhas sem PRIMARY KEY¶

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-06-30 · Decidido em: 2026-04-28

Contexto¶

O campo id de pabast_senhas é a ChaveUsu do ERP (VARCHAR(7)) e só é único dentro de um único ERP/cliente. Com vários clientes na mesma tabela centralizada (decisão 0003), a mesma ChaveUsu aparece legitimamente em mais de um cliente (ex. 1 0999 em onpetro e em vantroba), violando a PK original sobre id.

Decisão¶

A migração V6 dropa a PRIMARY KEY (id) e não coloca constraint no lugar. A unicidade do par (cliente_id, id) passa a ser garantida em software: AdminController e PabastSenhaRepository expõem apenas finders/updaters/deleters por par (findByClienteIdAndId, updateMutableFieldsByClienteIdAndId, deleteByClienteIdAndId, …). Os herdados findById/update/deleteById (que filtram por id sozinho) ficam proibidos por convenção — cruzariam clientes. Os endpoints admin usam …/pabast/users/{clienteId}/{id}.

Consequências¶

Schema enxuto, sem @EmbeddedId/@Id composto no Micronaut Data.
Disciplina de código: usar um finder por id sozinho é um bug latente (cruza clientes). Está documentado no CLAUDE.md do repositório e no guia do código.

Alternativas consideradas¶

PK composta (cliente_id, id) com @EmbeddedId: refator maior no entity/repositório/controllers sem ganho funcional perceptível. Descartado.
PK surrogate UUID + UNIQUE(cliente_id, id): custo similar e adiciona uma coluna sem dono. Descartado.