- Shipped
- 26 de agosto de 2026 às 01:55 UTC
- Author
- Kamo
- Commit
- f0f5063
LEAD CONTACT POINTS e LEAD COMUNICAÇÕES ganham o gerente do documento (assoc type, assoc object id) par para uma conta, um paciente ou um comércio O registo pode possuir comunicações sem pedir uma pista. Quatro passos, e a ordem é o ponto todo. Backfill em primeiro lugar: cada linha existente é de um lead, então assoc type = 'LEAD' e assoc object id = lead uid::text. Executá- lo após a troca de restrições construiria o novo índice único sobre nulos, impondo nada. Em seguida, troque a restrição única para o par proprietário. (org id, lead uid, canal, source id) é o que torna a ingestão idempotente — uma chamada RingCentral é visto duas vezes, uma pelo webhook e outra pela varredura da reconciliação — e com lead uid null para um paciente, Postgres trata cada um desses NULLs como distinto, assim o segundo avistamento insere uma duplicata. A nova restrição é adicionada ANTES que o antigo é deixado cair, então uma falha entre Deixam a mesa protegida por um e não por nenhum. Só então relaxar lead uid não é NULL. Ddl-auto do Hibernate: a atualização adiciona colunas mas nunca relaxa uma restrição, por isso isto não pode ser deixado à mapeamento — e fazê-lo antes do swap abrir exatamente a janela duplicada acima. Em seguida, verifique, lendo pg constraint e information schema de volta. A chaves primárias clínicas estavam corretas em Java e erradas na DDL emitida, e somente a leitura de pg constraint o mostrou. Uma linha à esquerda sem tipo de proprietário nunca apareceria em nenhuma linha temporal, então esse caso registra um erro ao invés de Relatório de sucesso. Idempotente por toda parte, e uma tabela em falta é ignorada em vez de falhar o boot — uma exceção aqui levaria cada corredor posterior com ele. 176 testes verdes.