DBeaver : Enregistrer ou Valider, guide des modes de transaction

Dans DBeaver, Enregistrer soumet les modifications non enregistrées de la grille. Valider finalise les opérations en attente prises en charge dans la transaction associée. Le fait qu’Enregistrer valide également ces opérations dépend du mode de transaction effectif et du comportement de la base de données, comme l’expliquent la documentation de l’éditeur de données et la documentation des modes de transaction.

Prenons une tâche de développement hypothétique : modifier le libellé d’un enregistrement jetable. La grille affiche désormais la bonne valeur. C’est un début utile, mais cela ne permet pas de savoir si la modification a atteint la base de données ou si sa transaction est terminée.

Ce guide explique comment distinguer ces états avant d’annoncer que le travail est terminé. Il suppose un accès autorisé à une base de développement jetable. L’exercice ci-dessous n’a pas été exécuté pour cet article.

Reconnaître les trois états d’une modification dans DBeaver

Modifications non enregistrées dans la grille

Une cellule modifiée peut encore correspondre à une modification locale non enregistrée. Enregistrer soumet les ajouts, modifications et suppressions non enregistrés ; Annuler abandonne les modifications non enregistrées. Les commandes documentées distinguent ces actions. Une cellule modifiée ne prouve à elle seule ni la soumission ni la validation.

Pour les développeurs qui créent des indicateurs d’état similaires, notre guide de la persistance avec Tiptap examine l’écart entre les modifications locales et les accusés de réception du serveur. Son modèle de stockage des documents est distinct du contrôle des transactions SQL.

Modifications exécutées dans une transaction ouverte

La validation manuelle introduit une autre limite. Les modifications de données prises en charge peuvent s’exécuter correctement tout en restant en attente jusqu’à la fin de leur transaction. Enregistrer peut faire disparaître les modifications non enregistrées de la grille sans valider les opérations dans la base. C’est le comportement attendu de la validation manuelle.

Modifications validées et vérifications restantes

Valider finalise les opérations en attente prises en charge. La validation automatique ordinaire valide les instructions après leur exécution, conformément aux règles des modes de transaction. Il faut encore vérifier que l’enregistrement prévu a été modifié sur la cible prévue.

Le diagramme couvre les modifications de lignes réussies et prises en charge. Il exclut les erreurs d’exécution et les instructions dont le comportement transactionnel diffère.

Enregistrer, Valider, Annuler et Annuler la transaction : choisir la bonne action

Les commandes interviennent à différents moments du cycle de modification. Ce tableau associe les commandes de l’éditeur de données à la sémantique des transactions de DBeaver.

Avec la validation automatique ordinaire, Enregistrer valide les instructions qui en résultent. Le mode manuel laisse les modifications prises en charge en attente. Lorsque la validation intelligente est activée, elle peut basculer en mode manuel avant la soumission. Un bouton Enregistrer désactivé ne suffit donc pas pour annoncer que la modification a été validée.

Prévisualiser le SQL avant d’enregistrer

Après avoir modifié une cellule, placez le focus sur une autre cellule. La documentation de la modification des données indique qu’Enregistrer et Annuler deviennent actifs après ce changement de focus. Ouvrez le menu déroulant d’Enregistrer, choisissez Générer le script et examinez l’aperçu des modifications.

Examinez attentivement la manière dont l’instruction identifie l’enregistrement. Cible-t-elle la ligne prévue, et la modification correspond-elle à votre tâche ? L’aperçu facilite l’examen ; il ne prouve ni l’autorisation ni la réussite de l’exécution. Si vos collègues ont besoin d’un processus de modification d’enregistrements plutôt que d’un accès SQL, le guide Baserow sur la création, la modification et la consultation compare ces actions de partage.

Choisir le mode de transaction avant de modifier les données

DBeaver documente la validation automatique et la validation manuelle comme modes de transaction. La validation intelligente modifie le comportement lorsque la validation automatique est active. Choisissez à quel moment vous souhaitez finaliser les opérations, en vous aidant de la documentation des modes de transaction pour vérifier les paramètres.

Une petite modification ne justifie pas automatiquement la validation automatique. Le mode manuel ne rend pas non plus les essais en production acceptables. La question utile est de savoir à quel moment cette modification autorisée doit être finalisée et quelles autres opérations appartiennent à sa transaction.

La validation intelligente peut changer la réponse en cours de travail

Lorsque la validation automatique est active, la validation intelligente bascule en mode manuel avant les instructions de modification reconnues, comme UPDATE, INSERT, DELETE, UPSERT et MERGE. L’enregistrement de modifications de données dans une table suit la même règle documentée. Le traitement ordinaire de SELECT ne déclenche normalement pas ce basculement. Consultez la documentation de la validation intelligente.

Cette classification n’offre aucune garantie générale concernant les procédures, les CTE ou tous les dialectes SQL. Elle ne prouve pas non plus que chaque SELECT est en lecture seule ou ne pose aucun verrou côté serveur.

Le paramètre facultatif de retour à la validation automatique en fin de transaction rétablit ce mode après une validation ou une annulation de transaction. Vérifiez de nouveau le mode avant l’opération suivante. Le comparatif des types de connexion intégrés indique que la validation intelligente est désactivée : sa disponibilité ne prouve donc pas que votre connexion l’utilise.

Vérifier la connexion derrière le libellé

Le type de connexion Production documenté utilise par défaut la validation manuelle ; les types Développement et Test utilisent la validation automatique. Ces types sont personnalisables, et l’initialisation de la connexion peut utiliser un mode par défaut ou explicite. Lisez l’état effectif dans la barre d’outils.

Avant toute modification, identifiez le point de connexion, la base de données, le schéma, l’utilisateur et les autorisations. Vérifiez aussi la connexion de l’éditeur actif. Une couleur ou un libellé de connexion sert de rappel. Cela ne prouve ni l’autorisation côté serveur ni que vous avez atteint l’hôte prévu.

Un onglet n’est pas une limite de transaction

Examinez les opérations en attente sur la connexion associée. DBeaver décrit Valider comme l’application de toutes les modifications en attente dans la transaction courante ; le périmètre peut donc dépasser la cellule visible. Un autre onglet ne prouve pas l’existence d’une transaction indépendante ; consultez la documentation des transactions avant de le supposer.

Dans le signalement 37599, TanguyP raconte avoir annoncé à un collègue qu’une tâche était terminée alors que les modifications n’étaient toujours pas validées après le choix du type de connexion Production. Il s’agit d’un témoignage attribué à une personne. Il ne fournit ni estimation de fréquence ni raison d’activer la validation automatique en production.

Une grille sans modifications apparentes est un mauvais critère d’achèvement. Indiquez plutôt l’issue de la transaction et le résultat de la relecture des données.

Appliquer la liste de contrôle Cible, État, Finalisation, Vérification

Cible, État, Finalisation, Vérification est la liste de contrôle éditoriale de ce guide. Elle regroupe les comportements documentés en une séquence d’examen ; ce n’est ni une fonctionnalité de DBeaver ni une méthode de déploiement testée.

Cible : définir le jeu de données de test jetable

Dans cet exercice hypothétique, un développeur autorisé modifie le libellé d’une tâche fictive dans un jeu de données de test jetable existant. DBeaver et un accès autorisé à la base de données sont déjà disponibles.

Vérifiez chaque point de contrôle avant de toucher à la grille.

Consignez la valeur initiale du libellé. Si vous ne pouvez pas expliquer les opérations déjà en attente, arrêtez-vous là. Changer de mode pour donner l’impression que l’interface est prête ne résout pas cette incertitude.

État : inspecter ce qu’Enregistrer a soumis

Modifiez la cellule prévue, déplacez le focus et prévisualisez le SQL généré. Vérifiez le prédicat qui identifie l’enregistrement et la modification proposée avant d’enregistrer. À ce stade, vous examinez une modification non enregistrée dans la grille.

Après l’enregistrement en mode manuel effectif, examinez les informations renvoyées par l’exécution. Les modifications réussies et prises en charge restent en attente dans la transaction selon le comportement documenté du mode manuel. Une erreur exige une investigation avant toute décision de validation. Un affichage modifié ne permet pas de lever l’incertitude sur le résultat de l’exécution.

Finalisation : décider après avoir examiné toute la transaction

Examinez toutes les opérations en attente associées. Le journal des transactions de DBeaver aide à inspecter les opérations et leur état dans la session courante.

Ne validez que les opérations dont vous comprenez le périmètre et l’objectif. Si vous les abandonnez, l’annulation de la transaction s’applique aux opérations non validées prises en charge. Une instruction ou une cible inattendue justifie un arrêt. Ne finalisez pas des opérations inconnues dans le seul but de faire disparaître un indicateur.

Vérification : relire l’enregistrement après la finalisation

Actualisez ou relisez l’enregistrement prévu après la fin de la transaction choisie, en vérifiant de nouveau la cible. Une connexion distincte dont vous comprenez le fonctionnement peut aider à évaluer la visibilité ; un deuxième onglet ne prouve à lui seul aucune indépendance. Vérifiez les règles d’isolation et d’instantanés de votre moteur de base de données. Pour un exemple propre à un moteur, consultez la documentation de l’isolation dans PostgreSQL, sans y voir une règle universelle de visibilité. Si la vérification dans l’application fait partie de votre tâche, contrôlez séparément sa politique d’actualisation et de cache au lieu de promettre la visibilité à partir de la grille.

Utilisez le plan de mesure suivant pour consigner un exercice sur des données jetables. Cet article ne contient aucune observation recueillie.

Comparez deux parcours distincts à la valeur initiale consignée. D’abord, modifiez le libellé fictif, quittez la cellule, inspectez l’aperçu et choisissez Annuler sans enregistrer. Le résultat local attendu est l’abandon de la modification non enregistrée. Actualisez et vérifiez également l’enregistrement ; l’état du bouton ne constitue pas une preuve suffisante.

Lors d’un passage distinct, modifiez le même enregistrement jetable et prévisualisez la modification. Confirmez le mode manuel effectif avant d’enregistrer, puis examinez les informations d’exécution et les opérations en attente. Pour abandonner cette modification, examinez le périmètre de sa transaction avant de l’annuler, puis relisez l’enregistrement. Comparez cette valeur à la valeur initiale. Excluez de l’exercice les opérations en attente sans rapport avec celui-ci.

Si une observation contredit le résultat attendu, conservez l’erreur et le contexte de connexion. Déterminez si les opérations ont été soumises et si la transaction est terminée avant toute autre tentative. Répéter aveuglément l’enregistrement peut rendre un résultat incertain plus difficile à expliquer.

Ce JSON consigne la liste de contrôle et l’état des éléments de preuve. Il ne s’agit ni d’une requête adressée à une base de données ni d’un résultat de test.

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

Les erreurs des équipes concernant les scripts et les opérations en attente

L’exécution d’une instruction diffère de celle d’un script

Exécuter une instruction SQL agit sur la requête sous le curseur ou sur le texte sélectionné. Exécuter un script SQL traite le script de l’éditeur ou les requêtes sélectionnées. Vérifiez l’action et la sélection avant l’une ou l’autre exécution, comme l’explique la documentation de l’exécution SQL.

Le traitement des scripts possède ses propres paramètres de type de validation : À la fin du script, Après chaque requête, Après chaque groupe de N requêtes et Aucune validation. La gestion des erreurs propose Arrêter + annuler la transaction, Arrêter + valider et Ignorer. Lisez ces deux paramètres. Le mode manuel de la barre d’outils ne suffit pas à garantir qu’un script quelconque sera atomique. L’exécution par un client natif nécessite son propre examen des règles applicables.

Un indicateur invite à enquêter

Ne considérez pas Enregistrer comme une validation inconditionnelle. Assimiler Annuler à une annulation de transaction constitue l’erreur inverse : cela attribue une action sur la base de données à une commande destinée aux modifications non enregistrées de la grille. Ces deux erreurs traduisent une mauvaise compréhension de l’état actuel des opérations.

La fenêtre des transactions en attente affiche les transactions actives sur les différentes connexions de la session courante. Le journal des transactions permet d’examiner les opérations de la session. Aucun des deux ne constitue un audit complet et durable du serveur ni ne prouve que tous les verrous pertinents sont visibles.

Finalisez délibérément les opérations au lieu de compter sur des paramètres d’inactivité configurables. Pour les attentes de migration PostgreSQL liées aux transactions, le guide distinct de diagnostic des index concurrents traite l’investigation côté moteur. Il ne donne aucune autorisation de valider des opérations en attente inconnues.

Limites et décisions de récupération

Les garanties d’annulation de transaction ne s’appliquent qu’aux opérations non validées prises en charge. Le comportement de la base de données, de l’instruction et du pilote détermine la limite réelle de la transaction ; une barre d’outils ne peut pas ajouter des capacités absentes du moteur. Consultez la documentation de la base déployée pour connaître les règles de visibilité et de rétention des ressources.

Comparez votre version et votre édition de DBeaver, votre pilote et vos paramètres personnalisés à la documentation actuelle du client. Une documentation en ligne ne prouve pas que votre installation se comporte de manière identique.

Après la validation, l’annulation de transaction ne peut plus annuler la modification. Une erreur nécessite alors une décision de correction ou de récupération autorisée séparément. Évitez d’improviser une réparation en production à partir de cette liste de contrôle destinée au développement.

Avant de partager des aperçus SQL ou des journaux, retirez les données clients et les identifiants d’accès tout en conservant assez de contexte pour expliquer l’issue de la transaction. Si la relecture des données reste non résolue, indiquez-le dans le compte rendu d’avancement. Cette incertitude compte davantage que l’apparence ordonnée de la grille.