Guardar ou confirmar no DBeaver: guia dos modos de transação

Guardar no DBeaver envia as alterações ainda não guardadas na grelha. Confirmar conclui as operações pendentes suportadas na transação associada. Saber se Guardar também confirma depende do modo de transação efetivo e do comportamento da base de dados, como explicam a referência do editor de dados e a referência dos modos de transação.

Considere uma tarefa hipotética de desenvolvimento: alterar uma designação num registo descartável. A grelha mostra agora o valor correto. É um começo útil, mas não demonstra se a alteração chegou à base de dados ou se a respetiva transação foi concluída.

Este guia explica como distinguir esses estados antes de comunicar que o trabalho está concluído. Pressupõe acesso autorizado a uma base de dados de desenvolvimento descartável. O exercício abaixo não foi executado para este artigo.

Reconheça os três estados de uma alteração no DBeaver

Alterações não guardadas na grelha

Uma célula editada pode ainda representar trabalho local não guardado. Guardar envia adições, edições e eliminações ainda não guardadas; Cancelar descarta modificações não guardadas. Os controlos documentados distinguem essas ações. Uma célula alterada, por si só, não comprova o envio nem a confirmação.

Para os programadores que criam indicadores de estado semelhantes, o nosso guia de persistência no Tiptap analisa a diferença entre edições locais e confirmações de receção pelo backend. O seu modelo de armazenamento de documentos é distinto do controlo de transações SQL.

Alterações executadas numa transação aberta

A confirmação manual introduz outra fronteira. As alterações de dados suportadas podem ser executadas com êxito e continuar pendentes até concluir a respetiva transação. Guardar pode resolver as edições não guardadas da grelha sem confirmar as operações na base de dados. Esse é o comportamento esperado da confirmação manual.

Alterações confirmadas e o que falta verificar

Confirmar conclui as operações pendentes suportadas. A confirmação automática normal confirma as instruções após a execução, de acordo com as regras dos modos de transação. Continua a ser necessário verificar se o registo pretendido foi alterado no destino correto.

O diagrama abrange alterações de linhas suportadas e executadas com êxito. Omite erros de execução e instruções com comportamentos transacionais diferentes.

Guardar, Confirmar, Cancelar e Reverter: escolha a ação certa

Os controlos atuam em momentos diferentes do ciclo de edição. Esta tabela combina os controlos do editor de dados com a semântica das transações do DBeaver.

Com a confirmação automática normal, Guardar confirma as instruções resultantes. O modo Manual deixa pendentes as alterações suportadas. A confirmação inteligente, quando ativada, pode mudar para Manual antes do envio. Por isso, um botão Guardar desativado fornece informação insuficiente para comunicar que a alteração está confirmada.

Pré-visualize o SQL antes de guardar

Depois de editar uma célula, desloque o foco para outra célula. A referência de edição descreve a ativação de Guardar e Cancelar após essa mudança de foco. Abra o menu pendente de Guardar, escolha Gerar script e reveja a Pré-visualização de alterações.

Observe atentamente como a instrução identifica o registo. Abrange a linha pretendida e a alteração corresponde à sua tarefa? A pré-visualização ajuda na revisão; não comprova autorização nem execução bem-sucedida. Se os colegas precisarem de um processo de edição de registos em vez de acesso SQL, o guia do Baserow para criar, editar e visualizar compara essas ações de partilha.

Escolha o modo de transação antes de editar

O DBeaver documenta a confirmação automática e Manual como modos de transação. A confirmação inteligente modifica o comportamento enquanto a confirmação automática está ativa. Escolha o momento em que pretende concluir a transação, consultando a referência dos modos de transação para verificar as definições.

Uma pequena edição não exige automaticamente confirmação automática. O modo Manual também não torna aceitável experimentar em produção. A questão útil é em que momento esta alteração autorizada deve ficar concluída e que outras operações pertencem à sua transação.

A confirmação inteligente pode mudar a resposta durante o processo

Com a confirmação automática ativa, a confirmação inteligente muda para Manual antes de instruções de modificação reconhecidas, como UPDATE, INSERT, DELETE, UPSERT e MERGE. Guardar edições de dados de tabelas segue a mesma regra documentada. O tratamento normal de SELECT geralmente não desencadeia essa mudança. Consulte a documentação da confirmação inteligente.

Essa classificação não oferece uma garantia geral para procedimentos, CTEs ou todos os dialetos SQL. Também não demonstra que todos os SELECT sejam apenas de leitura ou isentos de bloqueios no servidor.

A definição opcional Voltar à confirmação automática no fim da transação repõe esse modo após Confirmar ou Reverter. Verifique novamente antes da operação seguinte. A comparação dos tipos de ligação integrados indica que a confirmação inteligente está desativada, pelo que a disponibilidade da função não comprova que a sua ligação a utilize.

Verifique a ligação por detrás da designação

O tipo de ligação Produção documentado usa Manual por predefinição; Desenvolvimento e Teste usam confirmação automática. Esses tipos são personalizáveis, e a inicialização da ligação pode utilizar um modo predefinido ou explícito. Leia o estado efetivo na barra de ferramentas.

Antes de editar, identifique o ponto de ligação, a base de dados, o esquema, o utilizador e as permissões. Verifique também a ligação do editor ativo. Uma cor ou designação de ligação serve de lembrete. Não comprova autorização no servidor nem demonstra que chegou ao servidor pretendido.

Um separador não delimita uma transação

Reveja as operações pendentes na ligação associada. O DBeaver descreve Confirmar como a aplicação de todas as alterações pendentes na transação atual, pelo que o âmbito pode ir além da célula visível. Outro separador não comprova uma transação independente; consulte a documentação das transações antes de assumir essa independência.

Na ocorrência 37599, TanguyP relatou ter dito a um colega que uma tarefa estava concluída quando as alterações continuavam por confirmar, após escolher o tipo de ligação Produção. Trata-se de um relato com autoria identificada. Não fornece uma estimativa de frequência nem uma razão para ativar a confirmação automática em produção.

Uma grelha sem alterações pendentes é um critério de conclusão fraco. Comunique antes o resultado da transação e da leitura de verificação.

Aplique a lista de verificação Destino, Estado, Conclusão, Verificação

Destino, Estado, Conclusão, Verificação é a lista de verificação editorial deste guia. Combina os comportamentos documentados numa sequência de revisão; não é uma funcionalidade do DBeaver nem um método de implementação testado.

Destino: estabeleça os dados de teste descartáveis

Neste exercício hipotético, um programador autorizado altera a designação de uma tarefa fictícia em dados de teste descartáveis já existentes. O DBeaver e o acesso autorizado à base de dados já estão disponíveis.

Estabeleça cada ponto de verificação antes de tocar na grelha.

Registe o valor inicial da designação. Se não conseguir explicar as operações pendentes existentes, pare aí. Mudar de modo para que a interface pareça pronta não resolve essa incerteza.

Estado: inspecione o que Guardar enviou

Edite a célula pretendida, desloque o foco e pré-visualize o SQL gerado. Verifique o predicado que identifica o registo e a alteração proposta antes de Guardar. Neste momento, está a rever uma edição não guardada na grelha.

Depois de Guardar com o modo Manual efetivo, inspecione a informação de execução. As alterações suportadas executadas com êxito continuam pendentes na transação, segundo o comportamento Manual documentado. Um erro exige investigação antes de qualquer decisão de confirmar. Uma alteração no ecrã não esclarece um resultado de execução incerto.

Conclusão: decida depois de rever toda a transação

Reveja todas as operações pendentes associadas. O registo de transações do DBeaver ajuda a inspecionar as operações e o respetivo estado na sessão atual.

Confirme apenas operações cujo âmbito e finalidade compreende. Se as abandonar, Reverter aplica-se às operações suportadas ainda não confirmadas. Uma instrução ou um destino inesperado é motivo para parar. Não conclua operações desconhecidas apenas para limpar um indicador.

Verificação: leia o registo após a conclusão

Atualize ou volte a ler o registo pretendido depois de a transação escolhida terminar, verificando novamente o destino. Uma ligação separada cujo comportamento compreende pode ajudar a avaliar a visibilidade; um segundo separador, por si só, não comprova independência. Verifique as regras de isolamento e de instantâneos do seu backend. Para um exemplo específico de um backend, consulte a referência de isolamento do PostgreSQL, sem a tratar como uma regra universal de visibilidade. Se a verificação na aplicação fizer parte da tarefa, verifique separadamente a sua política de atualização e de cache, em vez de prometer visibilidade com base na grelha.

Utilize o plano de medição seguinte para registar um exercício descartável. Este artigo não contém observações recolhidas.

Compare dois percursos separados com o valor inicial registado. Primeiro, edite a designação fictícia, saia da célula, inspecione a pré-visualização e escolha Cancelar sem Guardar. O resultado local esperado é o abandono da edição não guardada. Atualize e verifique também o registo; o estado do botão é uma evidência insuficiente.

Numa passagem separada, edite o mesmo registo descartável e pré-visualize a alteração. Confirme o modo Manual efetivo antes de Guardar e, em seguida, inspecione a informação de execução e as operações pendentes. Para abandonar esta alteração, reveja o âmbito da transação antes de Reverter e leia novamente o registo. Compare esse valor com o inicial. Mantenha as operações pendentes não relacionadas fora do exercício.

Se uma observação contrariar o esperado, preserve o erro e o contexto da ligação. Determine se as operações foram enviadas e se a transação foi concluída antes de tentar outra coisa. Repetir Guardar às cegas pode tornar mais difícil explicar um resultado incerto.

Este JSON regista a lista de verificação e o estado das respetivas evidências. Não é um pedido à base de dados nem um resultado de teste.

{
  "checklist": "target-state-finish-verify",
  "steps": [
    "target",
    "state",
    "finish",
    "verify"
  ],
  "evidenceStatus": "not-collected"
}

O que as equipas interpretam mal sobre scripts e operações pendentes

Executar uma instrução e executar um script são ações diferentes

Executar instrução SQL atua sobre a consulta sob o cursor ou sobre o texto selecionado. Executar script SQL processa o script do editor ou as consultas selecionadas. Verifique a ação e a seleção antes de executar qualquer uma, como descrito na referência de execução SQL.

O processamento de scripts tem definições próprias de Tipo de confirmação: No fim do script, Após cada consulta, Após cada enésima consulta e Sem confirmação. O tratamento de erros oferece Parar + reverter, Parar + confirmar e Ignorar. Leia ambas as definições. O modo Manual na barra de ferramentas, por si só, não permite concluir que um script arbitrário será atómico. A execução por um cliente nativo exige a sua própria revisão de políticas.

Um indicador é um convite a investigar

Não trate Guardar como uma confirmação incondicional. Tratar Cancelar como uma reversão comete o erro oposto: atribui uma ação da base de dados a um controlo de edições não guardadas na grelha. Ambas as interpretações confundem o estado atual das operações.

A janela de transações pendentes mostra as transações ativas nas várias ligações da sessão atual. O registo de transações permite rever as operações da sessão. Nenhum constitui uma auditoria completa e duradoura do servidor ou comprova que todos os bloqueios relevantes estão visíveis.

Conclua deliberadamente, em vez de depender das definições configuráveis de inatividade. Para esperas em migrações PostgreSQL relacionadas com transações, o guia de diagnóstico de índices concorrentes trata separadamente a investigação no backend. Não autoriza a confirmação de operações pendentes desconhecidas.

Limites e decisões de recuperação

As garantias de reversão aplicam-se apenas a operações suportadas ainda não confirmadas. O comportamento da base de dados, da instrução e do controlador determina os limites reais da transação; uma barra de ferramentas não pode acrescentar capacidades que o backend não possui. Consulte a documentação da base de dados utilizada para conhecer a semântica de visibilidade e retenção de recursos.

Compare a versão, a edição, o controlador e as definições personalizadas da sua instalação do DBeaver com a documentação atual do cliente. Uma referência em linha não comprova um comportamento idêntico na sua instalação.

Após a confirmação, Reverter a transação não pode desfazer a alteração. Um erro exige então uma decisão de correção ou recuperação autorizada separadamente. Evite improvisar uma reparação em produção a partir desta lista de verificação para desenvolvimento.

Antes de partilhar pré-visualizações SQL ou registos, remova dados de clientes e credenciais, preservando contexto suficiente para explicar o resultado da transação. Se a leitura de verificação continuar por esclarecer, indique-o no relatório de estado. Essa incerteza é mais relevante do que o aspeto arrumado da grelha.