Staging et validation

Chaque édition dans DynoTable passe par une zone de staging avant de toucher DynamoDB. Vois-la comme une zone de staging git avec un verrou de sécurité : les éditions, créations et suppressions s’accumulent en diffs examinables, puis partent en lots transactionnels seulement quand tu valides.

Rien n’est écrit dans ta table tant que tu ne le dis pas.

Comment ça marche

Chaque table a sa propre zone de staging, partagée par chaque vue de cette table. Quand tu enregistres une édition d’élément, crées une ligne ou en supprimes une, le changement atterrit dans le panneau sous forme de diff par attribut — attributs ajoutés, retirés et modifiés affichés côte à côte. Les lignes affectées dans la grille sont teintées par opération :

• vert — un nouvel élément (création)
• orange — une mise à jour (cellules modifiées surlignées)
• rouge — une suppression (barrée)

Ouvre la même table dans deux onglets et ils affichent les mêmes changements en attente ; ferme puis rouvre un onglet et le stage est toujours là. Fermer un onglet ne jette jamais tes changements préparés.

Bascule le panneau avec ⌘⇧D. Fais glisser son bord pour le redimensionner.

Examiner les changements

Chaque carte de diff montre exactement ce qui va changer :

• Les scalaires se rendent ancien → nouveau avec un surlignage rouge/vert.
• Les longues chaînes montrent un diff inline au niveau du mot.
• Les Maps et Lists se rendent en JSON joliment formaté (attribut entier en v1).

Utilise le Rejeter par attribut d’une carte pour ramener un seul attribut à sa valeur d’origine. Rejette chaque attribut et tout le changement est abandonné.

Valider

Valide pour écrire tes changements préparés dans DynamoDB :

• Valider N envoie chaque changement préparé de cette table — à travers tous ses onglets.
• Valider seulement celui-ci envoie un seul changement depuis sa carte.

Les validations partent en lots TransactWriteItems avec des conditions de verrouillage optimiste : une mise à jour ne réussit que si les attributs tiennent encore les valeurs dont tu es parti, une création ne réussit que si l’élément n’existe pas déjà, et une suppression ne réussit que si l’élément est toujours là. Les gros stages sont automatiquement découpés pour rester dans les limites de transaction de DynamoDB.

Les raccourcis d’enregistrement de l’éditeur s’appliquent aussi ici :

• ⌘S — préparer (pas de validation)
• ⌘⇧S — enregistrer et valider
• ⌘⇧X — jeter tous les changements préparés (avec confirmation)

Depuis une sélection dans la grille, tu peux préparer des suppressions sans ouvrir l’éditeur :

• ⌘⌫ — préparer une suppression des lignes sélectionnées
• ⌘⇧⌫ — supprimer les lignes sélectionnées et valider

Conflits

Comme les validations utilisent le verrouillage optimiste, un changement validé par quelqu’un d’autre après que tu as préparé le tien est détecté plutôt que silencieusement écrasé. La carte affiche une bannière inline :

• Dérive — l’élément distant a changé sous toi. Rebaser sur le distant rafraîchit la base pour que tu puisses ré-examiner, ou Abandonner le changement.
• Supprimé à distance — l’élément n’existe plus. Abandonne le changement.
• Réseau indisponible — la validation n’a pas pu joindre DynamoDB. Réessayer ou abandonner.

Une validation s’arrête au premier lot échoué — les lots précédents réussis restent écrits, le reste n’est pas tenté, et les échecs remontent en conflits à résoudre.

Ce qui bloque les validations

Certains états sont en lecture seule et peuvent préparer mais pas valider — notamment une licence expirée ou en lecture seule. Le staging fonctionne toujours ; la validation se déverrouille de nouveau une fois que l’app est revenue à un état actif.