Come gestire le transazioni a lungo termine?

Se stai memorizzando una cronologia delle modifiche (bozze) con un indicatore per contrassegnare lo stato visibile pubblicamente, il pulsante Invia modifiche può semplicemente impostare lo stato di visualizzazione pubblicamente sullo stato della pagina. È possibile utilizzare una transazione per questo poiché serializzerebbe tutte le modifiche. Ciò è particolarmente utile se si implementa un sistema per il rollback di tali modifiche di stato alle configurazioni precedenti.

Una spiegazione più dettagliata sarebbe che se avessi tabelle come:

articoli (id, url)
article_titles (id, article, text, timestamp)
article_body (id, article, text, timestamp)
article_history (id, article, title, body, timestamp)

Quindi, quando il titolo viene modificato, inserisce solo un nuovo record. Quando il corpo viene modificato o salvato periodicamente, inserisce semplicemente un nuovo record del corpo. Ora quando colpisci, viene inserito in article_history e quando viene visualizzato pubblicamente per l'utente il renderer cattura il record article_history più recente e il titolo e il corpo corrispondenti.

(Nota, questo è solo un esempio per cercare di mettere in relazione ciò che hai descritto. Non sto dicendo che questo sia un progetto corretto per un CMS o una buona pratica).

Ci sono molti sistemi di gestione dei contenuti e ne ho usati solo un paio, ma penso che ciò che i sistemi di gestione dei contenuti fanno frequentemente sia mantenere due database o filesystem, uno per modificare il contenuto e l'altro per quello che vedono gli utenti. Conosco il sistema di gestione dei contenuti che usavo molto (Vignette, ora OpenText). Ci sono due parti separate, Gestione / Anteprima e Consegna. Gestione è dove si modifica e quando si desidera consentire agli utenti di vedere il contenuto, si pubblica alla consegna. La pubblicazione implica la copia dal database di gestione nel database di consegna.

Ciò significa che è possibile salvare le modifiche più volte prima della pubblicazione o non pubblicare mai. Per gli amministratori di contenuti, è molto più semplice utilizzare un sistema che ti consente di salvare e tornare al tuo lavoro più tardi e pubblicare quando sei pronto.

Pensa alle transazioni SQL come gruppi di query SQL eseguite insieme in una connessione per mantenere la coerenza del database, ad es. durante la rimozione dei dati, rimuovere anche le voci collegate dalle tabelle delle relazioni per mantenere pulito il database. Se si verifica un problema, è possibile utilizzare ROLLBACK per ripristinare le modifiche nella transazione SQL corrente. PostgreSQL può gestire da solo la coerenza e può fare molto di più con progetti più grandi.

È possibile registrare una cronologia delle modifiche o aggiungere un'altra colonna alla tabella (testo _draft). I visitatori vedrebbero comunque il testo originale, ma mentre verrai registrato come amministratore, puoi controllare i dati in questa colonna e visualizzarli al posto del testo originale. Aprendo i due regolarmente e in una finestra anonima puoi vedere facilmente le modifiche.

Uno degli approcci è il controllo delle versioni. Progetteresti la tua tabella di contenuti con version e active colonna. Ogni volta che si esegue il salvataggio automatico, si esegue il dump della versione ma non si contrassegna la riga come attiva. Una volta premuto Salva, eseguirai il bump della versione e pubblicherai il contenuto. Ti dà la cronologia completa al costo dei grandi tavoli. Penso che WordPress usi lo stesso approccio.