Mapeamento de Banco de Dados — tickets
Pilar: 04 — Banco de Dados / Tabelas
Status: 🟢 Implementado
Última Revisão Técnica: 2026-08-03
Módulos Conectados:gatein-server(app/models.py,app/api/public/tickets.py),gatein-app(src/screens/TicketScreen)
1. Visão Geral da Tabela tickets
A tabela tickets armazena a representação digital do Ticket de Liberação / Entrada de Pátio. O ticket é gerado automaticamente após a aprovação de um check-in e contém o snapshot dos dados operacionais (liberação de gate, número de doca, autorização de entrada) formatados de acordo com o layout dinâmico do terminal (layout_ref).
2. Atributos Físicos da Tabela tickets
| Coluna | Tipo SQL | Constraints | Descrição / Regra de Negócio |
|---|---|---|---|
id | BigInteger | PRIMARY KEY, autoincrement=True | ID interno do ticket |
appointment_id | BigInteger | FOREIGN KEY (appointments.id, CASCADE), NOT NULL, INDEX | Agendamento associado ao ticket |
appointment_ref | VARCHAR(100) | NOT NULL | Código de referência externa do agendamento |
terminal_id | BigInteger | FOREIGN KEY (terminals.id), NOT NULL, INDEX | Terminal emissor do ticket |
layout_ref | VARCHAR(50) | NULLABLE | Identificador da versão do layout JSON de ticket |
content | JSONB | NOT NULL, Default {} | Snapshot completo dos dados e campos formatados exibidos no ticket |
created_at | TIMESTAMPTZ | NOT NULL, Default now() | Timestamp de emissão do ticket |
updated_at | TIMESTAMPTZ | NOT NULL, Default now() | Timestamp de atualização |
3. Estrutura do Campo JSONB content
O campo content armazena os dados chave-valor renderizados na tela de Ticket do aplicativo mobile:
{
"ticket_number": "TKT-884920",
"gate_entrada": "Gate 04 - Pátio Norte",
"doca_atendimento": "Doca 12",
"codigo_qr": "984210492810",
"motorista": "Carlos Eduardo Silva",
"placa_veiculo": "ABC1D23",
"data_emissao": "2026-08-04T10:15:22Z"
}
4. Regras de Imutabilidade (RN-TKT-DB-XXX)
RN-TKT-DB-001: Imutabilidade do Content Snapshot
Uma vez inserido na tabela tickets, o objeto content não sofre atualizações retroativas mesmo se o agendamento pai for modificado posteriormente no ERP. Isso garante a integridade auditável do comprovante emitido para o motorista.
RN-TKT-DB-002: Remoção em Cascata (CASCADE)
Se um agendamento for removido fisicamente por rotinas de manutenção interna, todos os tickets vinculados via appointment_id são removidos em cascata.