Início / dba / Perguntas / 340916
Accepted
John Little
Asked: 2024-07-12 23:00:46 +0800 CST

Por que devo confirmar após ALTER TABLE DDL para tornar as alterações visíveis?

  • 772

Se eu executar isso no DBeaver:

alter table classes alter column reference set not null;

no meu banco de dados local, que só eu abri no DBeaver, ele foi concluído com êxito.

Mas não consigo abrir a tabela no explorer e a coluna ainda aparece como anulável.

Se eu tentar fechar o DBeaver, ele diz que há uma transação aberta, mas acho que não.

Porém, se eu executar commit, de repente tudo funciona, consigo visualizar a tabela e a coluna aparece como não nula.

Achei que as instruções DDL não tinham o conceito de confirmação e reversão: preciso confirmar após cada uma em meus scripts de atualização do Flyway?

postgresql

2 respostas

  1. Best Answer

    Alguns DBMS serão confirmados automaticamente após operações ddl, mas o postgres não é um deles.

    Verifique as configurações no dbeaver, você pode ter o commit automático desabilitado. Na versão do dbeaver que verifiquei está localizado aqui:

    confirmação automática dbeaver

    Em relação ao flyway, ele fará um commit no final de cada arquivo se nenhum erro ocorrer. Em geral, não coloque instruções de commit explícitas em seus arquivos de migração, pois isso irá interferir na propriedade idempotente dos arquivos de migração. Suponha uma migração de arquivos como:

    CREATE mytable t (x int);

COMMIT;

-- deliberate syntax error
CREATTE mytable u (x int);

    Flyway irá reverter a transação para a versão do esquema devido ao erro de sintaxe, mas a tabela t existe devido ao commit. Se você corrigir o erro de sintaxe e executar o flyway novamente, ele falhará porque t já existe.

    Flyway usa duas transações para cada arquivo de migração. Uma transação coloca um bloqueio exclusivo na tabela de histórico do esquema, a outra transação executa o arquivo de migração. Se a migração for bem-sucedida, a primeira transação insere a nova versão na tabela de histórico e faz o commit, ou seja, libera o bloqueio na tabela de histórico.

    Ter DDL sob controle de transação é uma coisa boa. Para DBMS que não suporta isso, você precisa implementar arquivos de desfazer, o que é um problema. Para DBMS que suportam isso, o flyway pode simplesmente reverter a transação. Escusado será dizer que é muito mais fácil

    • 3

  2. Achei que as instruções DDL não tinham o conceito de commit e rollback

    Você estava errado.

    preciso confirmar depois de cada um dos meus scripts de atualização do flyway?

    Você só precisa confirmar quando quiser que outras sessões vejam as alterações.

    • 0

relate perguntas