Guardar y confirmar en DBeaver: guía de los modos de transacción

Guardar en DBeaver envía las ediciones sin guardar de la cuadrícula. Confirmar finaliza las operaciones pendientes admitidas en la transacción asociada. Que Guardar también confirme los cambios depende del modo de transacción efectivo y del comportamiento de la base de datos, como explican la referencia del editor de datos y la referencia de los modos de transacción.

Piensa en una tarea de desarrollo hipotética: cambiar una etiqueta en un registro desechable. La cuadrícula ya muestra el valor correcto. Es un punto de partida útil, pero no demuestra que la edición haya llegado a la base de datos ni que su transacción haya finalizado.

Esta guía explica cómo distinguir esos estados antes de dar el trabajo por terminado. Presupone acceso autorizado a una base de datos de desarrollo desechable. El ejercicio que se presenta a continuación no se ha ejecutado para este artículo.

Reconoce los tres estados de una edición en DBeaver

Cambios sin guardar en la cuadrícula

Una celda editada puede seguir siendo una modificación local sin guardar. Guardar envía las inserciones, ediciones y eliminaciones sin guardar; Cancelar descarta las modificaciones sin guardar. Los controles documentados distinguen esas acciones. Una celda modificada, por sí sola, no demuestra ni el envío ni la confirmación.

Para quienes desarrollan indicadores de estado similares, nuestra guía de persistencia de Tiptap examina la distancia entre las ediciones locales y los acuses de recibo del servidor. Su modelo de almacenamiento de documentos es independiente del control de transacciones SQL.

Cambios ejecutados en una transacción abierta

La confirmación manual introduce otro límite. Los cambios de datos admitidos pueden ejecutarse correctamente y, aun así, quedar pendientes hasta que finalices su transacción. Guardar puede eliminar las ediciones sin guardar de la cuadrícula sin confirmar las operaciones de la base de datos. Ese es el comportamiento esperado de la confirmación manual.

Cambios confirmados y comprobaciones que aún faltan

Confirmar finaliza las operaciones pendientes admitidas. La confirmación automática ordinaria confirma las sentencias después de ejecutarlas, según las reglas de los modos de transacción. Aun así, debes comprobar que el registro previsto haya cambiado en el destino previsto.

El diagrama abarca los cambios de filas admitidos que se ejecutan correctamente. Excluye los errores de ejecución y las sentencias con un comportamiento transaccional diferente.

Guardar, Confirmar, Cancelar y Revertir: elige la acción adecuada

Los controles actúan en distintos puntos del ciclo de edición. Esta tabla combina los controles del editor de datos con la semántica de las transacciones de DBeaver.

Con la confirmación automática ordinaria, Guardar confirma las sentencias resultantes. El modo manual deja pendientes los cambios admitidos. La confirmación inteligente, cuando está activada, puede cambiar al modo manual antes del envío. Por tanto, que el botón Guardar esté desactivado aporta muy poca información para dar el cambio por confirmado.

Previsualiza el SQL antes de guardar

Después de editar una celda, mueve el foco a otra. La referencia de edición explica que Guardar y Cancelar se activan después de ese cambio de foco. Abre el menú desplegable de Guardar, elige Generar script y revisa la vista previa de los cambios.

Examina cómo identifica la sentencia el registro. ¿Apunta a la fila prevista y coincide el cambio con tu tarea? La vista previa ayuda a revisar, pero no demuestra ni la autorización ni que la ejecución haya sido correcta. Si tus compañeros necesitan un flujo de edición de registros en lugar de acceso SQL, la guía de Baserow para crear, editar y ver registros compara esas acciones para compartir información.

Elige el modo de transacción antes de editar

DBeaver documenta la confirmación automática y la manual como modos de transacción. La confirmación inteligente modifica el comportamiento mientras la automática está activa. Elige el punto en el que quieres finalizar las operaciones y consulta la referencia de los modos de transacción para comprobar los ajustes.

Una edición pequeña no exige automáticamente la confirmación automática. Tampoco el modo manual hace aceptable experimentar en producción. La pregunta útil es dónde debe finalizar este cambio autorizado y qué otras operaciones pertenecen a su transacción.

La confirmación inteligente puede cambiar la respuesta durante el proceso

Con la confirmación automática activa, la confirmación inteligente cambia al modo manual antes de las sentencias de modificación reconocidas, como UPDATE, INSERT, DELETE, UPSERT y MERGE. Guardar ediciones de datos de tablas sigue la misma regla documentada. El tratamiento habitual de SELECT normalmente no provoca ese cambio. Consulta la documentación de la confirmación inteligente.

Esa clasificación no ofrece una garantía general sobre los procedimientos, las CTE ni todos los dialectos SQL. Tampoco demuestra que toda sentencia SELECT sea de solo lectura o esté libre de bloqueos en el servidor.

El ajuste opcional para volver a la confirmación automática al finalizar la transacción restaura ese modo después de Confirmar o Revertir. Vuelve a comprobarlo antes de la siguiente operación. La comparación de los tipos de conexión integrados indica que la confirmación inteligente está desactivada, por lo que su disponibilidad no demuestra que tu conexión la utilice.

Comprueba la conexión que hay detrás de la etiqueta

El tipo de conexión Producción documentado utiliza el modo manual por defecto; Desarrollo y Pruebas utilizan la confirmación automática. Esos tipos se pueden personalizar, y la inicialización de la conexión puede utilizar un modo predeterminado o explícito. Consulta el estado efectivo en la barra de herramientas.

Antes de editar, determina el punto de conexión, la base de datos, el esquema, el usuario y los permisos. Comprueba también la conexión del editor activo. Un color o una etiqueta de conexión sirve de recordatorio. No demuestra la autorización en el servidor ni que hayas llegado al servidor previsto.

Una pestaña no delimita una transacción

Revisa las operaciones pendientes en la conexión asociada. DBeaver describe Confirmar como la aplicación de todos los cambios pendientes de la transacción actual, de modo que su alcance puede ir más allá de la celda visible. Otra pestaña no demuestra que exista una transacción independiente; consulta la documentación de transacciones antes de darlo por hecho.

En la incidencia 37599, TanguyP contó que había dicho a un compañero que una tarea estaba terminada cuando los cambios seguían sin confirmar tras elegir el tipo de conexión Producción. Es un único caso atribuido a su autor. No aporta una estimación de frecuencia ni un motivo para activar la confirmación automática en producción.

Una cuadrícula sin cambios pendientes es un criterio insuficiente para dar el trabajo por terminado. Informa del resultado de la transacción y de la lectura posterior del registro.

Aplica la lista de comprobación Destino, Estado, Finalización y Verificación

Destino, Estado, Finalización y Verificación es la lista de comprobación editorial de esta guía. Combina los comportamientos documentados en una secuencia de revisión; no es una función de DBeaver ni un método de despliegue probado.

Destino: prepara los datos de prueba desechables

En este ejercicio hipotético, un desarrollador autorizado cambia la etiqueta de una tarea ficticia en un conjunto existente de datos de prueba desechables. DBeaver y el acceso autorizado a la base de datos ya están disponibles.

Comprueba cada punto antes de tocar la cuadrícula.

Anota el valor inicial de la etiqueta. Si no puedes explicar las operaciones pendientes existentes, detente ahí. Cambiar de modo para que la interfaz parezca lista no resuelve esa incertidumbre.

Estado: inspecciona lo que ha enviado Guardar

Edita la celda prevista, mueve el foco y previsualiza el SQL generado. Comprueba la condición que identifica el registro y el cambio propuesto antes de pulsar Guardar. En este punto estás revisando una edición sin guardar de la cuadrícula.

Después de Guardar con el modo manual efectivo, inspecciona la información de ejecución. Los cambios admitidos que se han ejecutado correctamente permanecen pendientes en la transacción, según el comportamiento manual documentado. Un error exige investigar antes de decidir si confirmar. Un cambio en la pantalla no permite resolver la incertidumbre sobre el resultado de la ejecución.

Finalización: decide después de revisar toda la transacción

Revisa todas las operaciones pendientes asociadas. El registro de transacciones de DBeaver ayuda a inspeccionar las operaciones y su estado en la sesión actual.

Confirma únicamente las operaciones cuyo alcance y propósito comprendas. Si decides abandonarlas, Revertir se aplica a las operaciones admitidas sin confirmar. Una sentencia o un destino inesperados son motivo para detenerse. No finalices operaciones que desconoces solo para quitar un indicador.

Verificación: lee el registro después de finalizar

Actualiza o vuelve a leer el registro previsto después de que finalice la transacción elegida, comprobando de nuevo el destino. Una conexión independiente cuyo comportamiento entiendas puede ayudar a evaluar la visibilidad; una segunda pestaña por sí sola no demuestra independencia. Comprueba las reglas de aislamiento y de instantáneas de tu motor de base de datos. Como ejemplo específico de un motor, consulta la referencia de aislamiento de PostgreSQL, sin tomarla como una regla universal de visibilidad. Si la verificación en la aplicación forma parte de tu tarea, comprueba por separado su política de actualización y caché en lugar de prometer visibilidad a partir de la cuadrícula.

Utiliza el siguiente plan de medición para registrar un ejercicio con datos desechables. Este artículo no contiene observaciones recopiladas.

Compara dos recorridos separados con el valor inicial registrado. Primero, edita la etiqueta ficticia, sal de la celda, inspecciona la vista previa y elige Cancelar sin Guardar. El resultado local esperado es que se abandone la edición sin guardar. Actualiza y comprueba también el registro; el estado del botón no es una evidencia suficiente.

En una pasada separada, edita el mismo registro desechable y previsualiza el cambio. Confirma que el modo manual sea efectivo antes de Guardar y, después, inspecciona la información de ejecución y las operaciones pendientes. Para abandonar este cambio, revisa el alcance de su transacción antes de Revertir y vuelve a leer el registro. Compara ese valor con el inicial. Mantén fuera del ejercicio las operaciones pendientes ajenas a él.

Si una observación contradice lo esperado, conserva el error y el contexto de la conexión. Determina si se enviaron las operaciones y si finalizó la transacción antes de intentar nada más. Repetir Guardar a ciegas puede dificultar la explicación de un resultado incierto.

Este JSON registra la lista de comprobación y el estado de sus evidencias. No es una petición a la base de datos ni el resultado de una prueba.

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

Errores de los equipos con los scripts y las operaciones pendientes

Ejecutar una sentencia y ejecutar un script son acciones diferentes

Ejecutar sentencia SQL actúa sobre la consulta situada bajo el cursor o el texto seleccionado. Ejecutar script SQL procesa el script del editor o las consultas seleccionadas. Comprueba la acción y la selección antes de ejecutar cualquiera de ellas, como describe la referencia de ejecución SQL.

El procesamiento de scripts tiene sus propios ajustes de tipo de confirmación: Al finalizar el script, Después de cada consulta, Después de cada N consultas y Sin confirmación. La gestión de errores ofrece Detener + revertir, Detener + confirmar e Ignorar. Revisa ambos ajustes. El modo manual de la barra de herramientas, por sí solo, no demuestra que un script cualquiera vaya a ser atómico. La ejecución mediante un cliente nativo requiere su propia revisión de políticas.

Un indicador invita a investigar

No interpretes Guardar como una confirmación incondicional. Interpretar Cancelar como una reversión comete el error contrario: atribuye una acción de base de datos a un control destinado a ediciones sin guardar de la cuadrícula. Ambos errores parten de una interpretación equivocada del estado actual de las operaciones.

La ventana de transacciones pendientes muestra las transacciones activas de las distintas conexiones de la sesión actual. El registro de transacciones permite revisar las operaciones de la sesión. Ninguno constituye una auditoría completa y persistente del servidor ni demuestra que todos los bloqueos relevantes sean visibles.

Finaliza de forma deliberada en lugar de confiar en los ajustes configurables de inactividad. Para las esperas de migraciones de PostgreSQL relacionadas con transacciones, la guía de diagnóstico de índices concurrentes aborda por separado la investigación en el motor de base de datos. No concede permiso para confirmar operaciones pendientes que desconoces.

Límites y decisiones de recuperación

Las garantías de reversión solo se aplican a operaciones admitidas sin confirmar. El comportamiento de la base de datos, de la sentencia y del controlador determina el límite real de la transacción; una barra de herramientas no puede añadir capacidades que el motor no tenga. Consulta la documentación de la base de datos desplegada para conocer la semántica de visibilidad y retención de recursos.

Contrasta la versión, la edición, el controlador y los ajustes personalizados de tu instalación de DBeaver con la documentación actual del cliente. Una referencia en línea no demuestra que tu instalación se comporte de forma idéntica.

Después de confirmar, Revertir la transacción no puede deshacer el cambio. Un error requiere entonces una decisión de corrección o recuperación autorizada por separado. Evita improvisar una reparación en producción a partir de esta lista de comprobación para desarrollo.

Antes de compartir vistas previas de SQL o registros, elimina los datos de clientes y las credenciales, conservando contexto suficiente para explicar el resultado de la transacción. Si la lectura posterior sigue sin resolverse, indícalo en el informe de estado. Esa incertidumbre importa más que el aspecto ordenado de la cuadrícula.