-- ---------------------------------------------------------------------------
-- Os aparelhos dos clientes para o push pelo Firebase: `clientes_aparelhos`
-- (D461, a segunda parte da migracao do push, 10/10/2026).
--
--   mysql franquia_producao < scripts/migracao-clientes-aparelhos.sql
--
-- NA COPIA LOCAL (`franquiabv_dev`) DESDE 11/10/2026: o dono autorizou criar
-- esta tabela nos dois bancos da copia (a resposta 72 do lote, a opcao (c),
-- como o indice de `id_pai` na pergunta 62), e ela rodou la como o laco do
-- `docs/ensaio-geral-do-corte.md` a roda. Por isso a migracao esta no laco da
-- copia, ao lado das outras sete, e o cabecalho nao a proibe mais -- o
-- `scripts/conferir-passo-zero-do-corte.php` confere as duas coisas juntas.
-- Na copia ela nao faz mais nada: `CREATE TABLE IF NOT EXISTS`.
--
-- O QUE ELA GUARDA. O aplicativo novo manda ao ERP o identificador do aparelho
-- no Firebase -- o token de registro do FCM ou o FID (o Firebase Installation
-- ID, para onde o FCM esta migrando; os dois valem, e `tipo` diz qual) --, pela
-- rota `POST /api/v4/clientes/:id/aparelhos`, com a sessao do cliente (D59).
-- O push pelo FCM sai para os aparelhos daqui; o OneSignal nao usa a tabela.
--
-- UM APARELHO E DE UM CLIENTE POR VEZ: o identificador e UNICO, e o mesmo token
-- que chega de outro cliente MUDA de dono no registro. Duas linhas com o mesmo
-- token mandariam o push de um cliente ao aparelho de outro. O identificador e
-- `ascii_bin`: o token e o FID diferenciam maiuscula de minuscula, e a
-- comparacao padrao do `utf8mb3` nao.
--
-- O TELEFONE E O DA SESSAO QUE REGISTROU (achado da verificacao, 10/10/2026):
-- a sessao V4 alcanca um cliente enquanto o telefone dele for o da sessao, e o
-- aparelho so recebe o push do cliente enquanto `clientes.telefone_sem_mascara`
-- for este. O telefone digitado errado, ou reciclado pela operadora, e depois
-- corrigido pela unidade nao deixa o aparelho de quem tinha o numero recebendo
-- o push do cliente para sempre.
--
-- A CHAVE ESTRANGEIRA APAGA EM CASCATA: o cliente que sai leva os aparelhos
-- (e o que a LGPD pede de um dado que liga um aparelho a uma pessoa). O ERP
-- inativa cliente, nao apaga; quem apaga sao as fixtures da suite.
--
-- IDEMPOTENTE: `CREATE TABLE IF NOT EXISTS`. O DDL e o mesmo do `mysql.sql`
-- (menos o `AUTO_INCREMENT=1`), e o portao do passo 0 compara os dois.
--
-- ---------------------------------------------------------------------------
-- ESTA MIGRACAO PRECISA ESTAR EM PRODUCAO ANTES DO PASSO 1 -- o passo 0 (D323).
--
-- O passo 1 refaz o `mysql.sql` a partir da estrutura de producao. Sem a tabela
-- la, ela some do `mysql.sql` e do `schema.sql`, e a rota do aparelho responde
-- 503 ("indisponivel", em JSON) desde o primeiro dia.
--
-- PARA O CODIGO DE PRODUCAO A TABELA VAZIA E INOFENSIVA: com `push.provedor` em
-- `onesignal` (o padrao, e o da producao ate o aplicativo novo) o envio nao a le
-- nem a escreve; so a rota do aparelho a escreve. Cria-la nao copia tabela
-- nenhuma: e uma tabela nova, e a chave estrangeira so pede uma trava curta de
-- metadados em `clientes`.
--
-- NO SERVIDOR DE TESTE (o BVIP): o `deploy-teste.sh` nao roda migracao. O
-- `atualizar` recusa a mudanca de esquema, e a tabela entra pela mao do dono,
-- depois do `ACEITAR_ESQUEMA=sim ... atualizar` -- E DE NOVO DEPOIS DE TODO
-- `base` com uma copia exportada antes de 11/10/2026 (a de 02/10, e a que subia
-- no dia), que recria o banco sem a tabela. A copia exportada da `franquiabv_dev`
-- depois disso ja a leva, e antes dela o endurecimento precisa esvazia-la e a
-- regua conta-la (D327). O comando esta em `docs/ambiente-teste.md` ("A tabela
-- dos aparelhos").
-- ---------------------------------------------------------------------------

CREATE TABLE IF NOT EXISTS `clientes_aparelhos` (
  `id` int NOT NULL AUTO_INCREMENT,
  `cliente` int NOT NULL,
  `telefone` varchar(30) NOT NULL,
  `identificador` varchar(255) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
  `tipo` varchar(10) NOT NULL,
  `plataforma` varchar(10) NOT NULL,
  `versao_app` varchar(30) DEFAULT NULL,
  `data_criacao` datetime NOT NULL,
  `data_atualizacao` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uq_clientes_aparelhos_identificador` (`identificador`),
  KEY `idx_clientes_aparelhos_cliente` (`cliente`),
  CONSTRAINT `FK_CLIENTES_APARELHOS_cliente` FOREIGN KEY (`cliente`) REFERENCES `clientes` (`id`) ON DELETE CASCADE ON UPDATE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;

-- Conferencia. O esperado: a tabela, com o indice unico do identificador.
SELECT index_name                                         AS indice,
       GROUP_CONCAT(column_name ORDER BY seq_in_index)    AS colunas,
       MAX(non_unique)                                    AS nao_unico
  FROM information_schema.statistics
 WHERE table_schema = DATABASE()
   AND table_name = 'clientes_aparelhos'
 GROUP BY index_name
 ORDER BY index_name;