- Navios
- 19 de agosto de 2026 às 07:54 UTC
- Autor
- Kamo
- Enviar
- cbad368
Espelha o novo campo `User.isFake`. Quatro declarações, e a ordem é o todo migração: YugabyteDB rejeita `ADD COLUNN ... NOT NULL` em uma tabela povoada — rejeitando toda a declaração, não apenas a cláusula ofensiva — por isso a coluna chega nula, é recheado, ganha seu DEFAULT, e só então é apertado. Colapso estes em um ALTER produz uma migração que registra um aviso e deixa a coluna ausente, que é saída em forma de sucesso para um total não-op. `@Order(0)` por convenção de adição de coluna. O momento em que a entidade de compartilhamento-lib mapeia `is fake`, cada corredor posterior que carrega um `User` através do JPA emite-o em seu SELECT, assim uma migração tardia nunca seria alcançada — um corredor anterior morre em `colunn u1 0.is fake não existe` e leva a corrida para baixo primeiro. O índice é parcial (`WHERE is fake = TRUE`). A pergunta do guarda é "que identidades são sinalizado", e em uma tabela onde efetivamente cada linha é FALSE um índice completo na coluna é peso morto, enquanto uma parcial contém um punhado de entradas. O backfill's `WHERE is fake IS NULL` é suporte de carga, não decoração: KamoInitializer re-runs na íntegra cada vez, e um desnudo `UPDATE users SET is fake = FALSE` seria silenciosamente desempacotar todas as contas que um operador tinha deliberadamente escondido, em cada execução. Um teste afirma Essa cláusula ainda existe. Aplicado à produção 2026-08-19; todas as cinco declarações registradas aplicadas, SUCESSO CONSTRUTO. Coluna verificada como `boolean NOT NULL DEFAULT false` com o índice parcial presente.