Largue os Cheques Ordinais congelados que estavam falhando cada novo valor de enum

FixInitializerService
Navios
22 de agosto de 2026 às 23:17 UTC
Autor
Kamo
Enviar
b31fb30

imgs assoc id check permitido assoc id 0.13. ImageAssocType.PICTURE FRAME is Ordinal 14, então cada upload do Picture Frame o violou. Hibernate escreve CHECK (col BETWEN 0 AND N) para um @Enumerado(ORDINAL) coluna quando cria a tabela e nunca mais atualiza-lo, então N é o o tamanho de Enum no dia em que a mesa foi feita. Adicionar um valor e cada inserção levar o novo ordinal viola uma restrição que ninguém se lembra existe. A falha é invulgarmente opaca porque ImageService.uploadDocument é @Transactional: a violação roda todo o método de volta, tomando a linha Img já tinha escrito com ele. Assim, não há nenhuma linha de carga falhada, nenhuma linha parcial estado, e nada na base de dados apontando para a causa — apenas um genérico erro. Diagnosticá-lo significava excluir o portão MIME, a lista branca da extensão, limites multipartes e a cadeia proxy primeiro. imgs client mime check permitido 0...35 contra um ImageMimeType que tem exactamente 36 valores. Cheio. O próximo tipo MIME que alguém adicionou teria quebrado Cada upload na plataforma em vez de um recurso, por isso é deixado aqui também, juntamente com o antigo check client mime escrito à mão (teto 99) e verificação sig template status, que está igualmente cheio em 0.2. Caiu em vez de se alargar, que é o que... já faz para as tabelas de direitos e pela mesma razão: @Enumerado aplica valores válidos em Java, então a verificação do banco de dados é redundante, e O alargamento só move a bomba em vez de a desarmar. Já aplicado à produção.

Todas as alterações

Como o que vês no transporte?

Cada uma dessas atualizações pousa automaticamente em seu espaço de trabalho. Comece grátis e veja crescer semana após semana.

Começar Livre Para SempreVer Preços