Perché una GUI di database non dovrebbe mai scrivere direttamente

Ogni GUI di database ha un momento in cui un clic si trasforma in una scrittura sulla produzione. Abbiamo deciso che quel momento non dovrebbe esistere. In DynoTable, nulla di ciò che fai — né la modifica di un Item, né un'eliminazione di massa, né la modifica di un agente AI — tocca DynamoDB direttamente. Ogni scrittura atterra in un'area di staging come diff revisionabile per attributo, e viene inviata solo quando un umano ne esegue il commit.

Il modello mentale verso cui abbiamo costruito è git: un'area di staging per la revisione e un commit che si comporta come git push --force-with-lease — riesce solo se il remoto ha ancora l'aspetto che avevi visto l'ultima volta. Questo articolo è l'ingegneria sottostante: il bug cross-tab che ha ridisegnato l'intero progetto, il refactor il cui output principale è stato codice eliminato e perché l'arrivo degli agenti AI ha trasformato una comodità di UX nel muro di sicurezza portante.

Le scritture sono diff

Le modifiche si accumulano in un'area di staging locale basata su SQLite e vengono mostrate come diff card — vecchio valore, nuovo valore, per attributo — in un pannello laterale. Le righe si colorano nella griglia, così lo stato in staging è visibile dai dati, non solo dal pannello. Il commit invia l'insieme in staging come transazioni DynamoDB, suddiviso in blocchi secondo i limiti del servizio (100 Item per transazione, con budget in byte per operazione e per richiesta), in sequenza, con un timeout di 30 secondi per blocco.

La documentazione sullo staging copre il flusso di lavoro quotidiano. Ciò che non copre è in base a cosa è indicizzata l'area di staging — che si è rivelata la decisione più determinante del sistema.

Indicizzata sulla tabella, non sulla Tab

La prima versione limitava ogni area di staging alla Tab che l'aveva creata. Quel progetto produceva un bug reale: lo strumento di staging dell'AI derivava il proprio target dalla Tab attiva, e la sua guardia saltava le Tab che non sono viste di tabella. Così, se chiedevi all'assistente di correggere una riga mentre era in focus una Tab SQL Workbench, la modifica veniva messa in staging nell'area di staging del Workbench — e il chip «mostra la modifica in staging» apriva la Tab sbagliata.

Peggio ancora, anche il lock del commit era per Tab. Due Tab che visualizzavano la stessa tabella detenevano due lock indipendenti — il che significa che entrambe potevano eseguire il commit delle stesse righe in staging sul DynamoDB reale in modo concorrente. Una race di doppio commit sulla produzione, incorporata nel modello dei dati.

La soluzione è stata re-indicizzare tutto in base all'identità della tabella — {profile, region, tableName} — invece che in base alla Tab:

• Un'area di staging per tabella, visibile da ogni sua vista, che sopravvive alla chiusura e riapertura della Tab. L'AI può mettere in staging senza alcuna Tab di tabella aperta.
• Un lock del commit per tabella. La race di doppio commit non è «gestita» — è irrappresentabile.
• La classe di bug della Tab sbagliata è sparita per costruzione: non c'è alcuna Tab nella chiave.

E la re-indicizzazione ha eliminato più codice di quanto ne abbia aggiunto. Lo sweep di avvio che faceva la garbage collection delle aree di staging per le Tab chiuse? Un revisore l'ha segnalato come distruttivo per la funzionalità nel nuovo modello — le aree di staging non muoiono più con le Tab — quindi è stato rimosso del tutto. Lo scarto alla chiusura della Tab e la sua finestra di conferma: rimossi. L'unico vero orfano rimasto è un profilo di connessione eliminato, che si propaga in cascata in modo esplicito.

La migrazione stessa è stata la prima del repo a mutare le righe: una ricostruzione manuale della tabella SQLite che deduplicava le righe legacy per Tab con una window ROW_NUMBER() OVER (PARTITION BY …) (vince la modifica più recente) e riempiva la nuova chiave con separatori char(0), byte-identici al costruttore di chiavi del runtime. Quel giorno le migrazioni che mutano le righe hanno ottenuto il proprio harness di test seed-then-migrate.

--force-with-lease, per DynamoDB

Una UI di revisione non vale nulla se ciò che hai revisionato non è ciò che viene scritto. Tra lo staging e il commit, qualcun altro potrebbe aver modificato la riga. Perciò ogni operazione di commit porta con sé espressioni di condizione che ancorano la scrittura all'esatto snapshot che hai revisionato — blocco ottimistico, attributo per attributo:

• Un create asserisce che l'Item non esista già.
• Un update asserisce che ogni attributo che stai modificando contenga ancora il valore che hai visto quando l'hai messo in staging.
• Persino una rimozione asserisce che l'attributo sia ancora uguale al suo vecchio valore — se un collega ha cambiato note da "old" a "new" mentre la tua rimozione di note era in staging, il commit non deve eliminare in silenzio la sua modifica.

Quando una condizione fallisce, DynamoDB annulla l'intera transazione e ci dice quale Item è andato alla deriva. Quella riga riceve un banner di conflitto — esegui il rebase sul valore live o annulla — anziché una sovrascrittura silenziosa in una direzione o nell'altra.

E in caso di fallimento di un blocco, il committer si ferma. I blocchi già confermati restano confermati, il blocco fallito viene annullato in modo atomico, nulla di ulteriore viene tentato. Abbiamo respinto deliberatamente la continuazione best-effort: uno strumento di revisione che continua a scrivere oltre un conflitto sta applicando un insieme di modifiche che nessuno ha revisionato.

Il refactor che ha eliminato un sottosistema

I commit sono a lunga durata: l'app registra ciascuno in un replay registry, così che un ricaricamento del renderer — o una seconda finestra — possa riagganciarsi e osservarlo terminare. Col tempo, tre diversi percorsi di codice agganciavano ciascuno due observer per commit, e un intero meccanismo di arbitraggio è cresciuto attorno a un'unica domanda: quale observer può rilasciare il lock del commit? Aveva un nome tutto suo che incuteva timore (ownsLockOnBeforeRegistration), un blocco di commento che spiegava una race di ordinamento IPC e un tracker di toast da 230 righe.

La soluzione è stata un unico proprietario: una Commit Session che si aggancia esattamente una volta per commit, possiede il lock in modo esclusivo, proietta l'avanzamento nello store e garantisce che la sua chiamata di avvio si risolva su ogni percorso di uscita — non si blocca mai, non rifiuta mai. Il meccanismo di arbitraggio e il tracker non sono stati ricollocati; sono stati eliminati. Il benchmark di memoria che sollecita il pannello di staging ha ridotto di circa un terzo il suo heap. Il miglior commento di code review ricevuto quel mese: «questa PR è per lo più rossa».

Da quel modello di proprietà discendono due comportamenti che consideriamo requisiti minimi per qualsiasi strumento che scrive in produzione: un commit in corso sopravvive a un ricaricamento del renderer (la sessione si riaggancia e completa), e sopravvive persino al passaggio della tua licenza a sola lettura a metà commit — i nuovi commit vengono bloccati, ma una scrittura già in corso viene osservata fino alla fine, mai abbandonata applicata a metà.

Perché il formato wire è deliberatamente brutto

I valori in staging sono memorizzati come envelope tipizzati DynamoDB grezzi — {N: "42"}, {S: "42"} — non come JSON unmarshalled più amichevole. Due motivi. Il diff deve essere consapevole del tipo: {N: "1"} e {S: "1"} sono valori diversi, e un hash di chiave primaria costruito su valori unmarshalled li farebbe collidere. E il round-trip deve essere senza perdite: i wrapper numerici unmarshalled dell'SDK non sopravvivono alla serializzazione JSON dentro SQLite e ritorno, e l'uguaglianza profonda rispetto all'input utente si rompe. Il percorso di commit usa il client grezzo per lo stesso motivo — ciò che hai revisionato è byte per byte ciò su cui viene imposta la condizione e ciò che viene scritto.

Poi sono arrivati gli agenti

Lo staging precede le nostre funzionalità AI, ma è il motivo per cui hanno potuto essere rilasciate. Lo strumento di scrittura dell'assistente mette in staging; la sua stessa descrizione dice al modello — alla lettera:

The user reviews + commits from the staging panel —
this tool never writes to DynamoDB directly.

Non esiste uno strumento di commit. Non protetto da permessi, non sottoposto ad audit — assente. Il server MCP espone lo stesso confine in modo strutturale: il suo scope di consenso intermedio si chiama letteralmente «read + stage». Un agente con prompt injection a quello scope può proporre spazzatura, e il raggio d'azione è una diff card che un umano legge. E poiché i commit portano blocchi ottimistici per attributo, persino una modifica obsoleta di un agente non può sovrascrivere in silenzio una modifica umana concorrente — emerge come un conflitto, come tutto il resto.

Abbiamo scritto di come rendere affidabili le query dell'agente; lo staging è l'altra metà — rendere noiose le sue scritture.

Cosa pretendere da qualsiasi strumento che scrive nel tuo database

• Un passaggio di revisione tra l'intento e la scrittura — diff, non finestre di conferma.
• Concorrenza ottimistica sullo snapshot revisionato, incluse eliminazioni e rimozioni — mai last-writer-wins.
• Batch atomici con halt-on-failure, non continuazione best-effort oltre un conflitto.
• Un percorso di scrittura che sopravvive a un crash o a un ricaricamento senza lasciare un insieme applicato a metà.
• Per l'AI: lo staging come unica primitiva di scrittura che un agente possiede — una capacità mancante batte una protetta.

La documentazione sullo staging mostra il flusso di lavoro, e modificare i dati DynamoDB copre le basi che protegge. Oppure scarica DynoTable, metti in staging qualche modifica con ⌘S e guarda una modifica di massa diventare qualcosa che puoi davvero leggere prima che accada.