Staging e commit
Ogni modifica in DynoTable passa attraverso un'area di staging prima di toccare DynamoDB. Pensala come un'area di staging di git con una sicura: modifiche, creazioni ed eliminazioni si accumulano come diff rivedibili, poi partono come solo quando fai il commit.
Niente viene scritto sulla tua tabella finché non lo dici tu.
Come funziona
Ogni tabella ha la propria area di staging, condivisa tra ogni vista di quella tabella. Quando salvi una modifica di item, crei una riga o ne elimini una, la modifica atterra nel pannello come diff per attributo — attributi aggiunti, rimossi e cambiati mostrati affiancati. Le righe interessate nella griglia sono colorate per operazione:
- verde — un nuovo item (creazione)
- arancione — un aggiornamento (celle cambiate evidenziate)
- rosso — un'eliminazione (barrata)
Apri la stessa tabella in due tab e mostrano le stesse modifiche in sospeso; chiudi e riapri un tab e lo stage è ancora lì. Chiudere un tab non scarta mai le tue modifiche in staging.
Attiva il pannello con ⌘⇧D. Trascina il suo bordo per ridimensionarlo.
Rivedere le modifiche
Ogni card di diff mostra esattamente cosa cambierà:
- Gli scalari vengono renderizzati vecchio → nuovo con evidenziazione rossa/verde.
- Le stringhe lunghe mostrano un diff inline a livello di parola.
- Map e List vengono renderizzati come JSON formattato (per intero attributo nella v1).
Usa il Rifiuta per attributo di una card per riportare un singolo attributo al suo valore originale. Rifiuta ogni attributo e l'intera modifica viene scartata.
Fare il commit
Fai il commit per scrivere le tue modifiche in staging su DynamoDB:
- Commit N invia ogni modifica in staging di quella tabella — su tutti i suoi tab.
- Commit solo di questo invia una singola modifica dalla sua card.
I commit partono come batch TransactWriteItems con condizioni di locking
ottimistico: un aggiornamento riesce solo se gli attributi mantengono ancora i
valori da cui sei partito, una creazione riesce solo se l'item non esiste già, e
un'eliminazione riesce solo se l'item è ancora presente. Gli stage grandi vengono
automaticamente suddivisi in chunk per stare entro i limiti di transazione di
DynamoDB.
Le combinazioni di salvataggio dell'editor si applicano anche qui:
- ⌘S — staging (senza commit)
- ⌘⇧S — salva e committa
- ⌘⇧X — scarta tutte le modifiche in staging (con conferma)
Da una selezione nella griglia puoi mettere in staging eliminazioni senza aprire l'editor:
- ⌘⌫ — mette in staging l'eliminazione delle righe selezionate
- ⌘⇧⌫ — elimina e committa le righe selezionate
Conflitti
Poiché i commit usano il locking ottimistico, una modifica committata da qualcun altro dopo che hai messo la tua in staging viene rilevata anziché sovrascritta in silenzio. La card mostra un banner inline:
- Drift — l'item remoto è cambiato sotto di te. Rebase su remoto aggiorna la baseline così puoi ri-rivedere, oppure Annulla la modifica.
- Eliminato da remoto — l'item non esiste più. Annulla la modifica.
- Rete non disponibile — il commit non è riuscito a raggiungere DynamoDB. Riprova o annulla.
Un commit si ferma al primo batch fallito — i batch precedenti riusciti restano scritti, il resto non viene tentato, e i fallimenti emergono come conflitti da risolvere.
Cosa blocca i commit
Alcuni stati sono in sola lettura e possono mettere in staging ma non committare — più di tutti una licenza scaduta o in sola lettura. Lo staging funziona comunque; il commit si sblocca di nuovo una volta che l'app torna in uno stato attivo.