Metodi per la versione dei documenti generati dall'utente

Question

Metodi per la versione dei documenti generati dall'utente

#1 da (13 voti)
#2 da (5 voti)
#3 da (3 voti)
#4 da (1 voti)
#5 da (1 voti)

8

Ho un documento online che viene essenzialmente memorizzato nel database come stringa XML.

Sto pensando a un modo per implementare il controllo delle versioni del documento per l'utente. In modo che l'utente possa tornare alle versioni precedenti del documento.

aggiornamento Nel mio caso si tratta di un'applicazione Web con centinaia di migliaia di utenti. Un utente può memorizzare una quantità illimitata di documenti. L'XML per documento è memorizzato nel campo blob MySQL quindi non è piccolo. Alla fine ho bisogno di superare i limiti in qualche modo, ma questo è un argomento diverso tutti insieme.

C'è un modo standard per avvicinarsi a questo? Devo memorizzare solo le differenze tra le versioni? Quali sono le altre cose che devo considerare?

design versioning architecture

posta dev.e.loper 24.05.2012 - 17:55

fonte

5 risposte

Leggi altre domande sui tag design versioning architecture

Che cosa dice freelance a lungo termine sull'esperienza di uno sviluppatore? [chiuso] Perché per-each ha due punti invece di "in"?

score 13 · Answer 1

Perché non utilizzare un repository di controllo del codice sorgente? Richiederà meno spazio di archiviazione, farà tutto ciò che desideri attualmente e ti permetterebbe facilmente di estendere ulteriormente il concetto a rami, tag, ecc ... tutto ciò che ottieni da un RCS. Perché reinventare la ruota?

score 5 · Answer 2

Dato che lo stai facendo in un database, il modo più semplice per eseguire la versione della stringa XML è creare una nuova tabella Cronologia con le seguenti colonne:

ID cronologia
Nuova stringa XML (colonna facoltativa)
Stringa XML precedente
Inserisci data / ora

Inserisci una riga in questa tabella Cronologia prima di aggiornare la riga sulla tabella di stringhe XML.

score 3 · Answer 3

Is there a standard way to approach this?

Per un approccio basato su standard, dai un'occhiata all'estensione di Delta-V a WebDAV (a sua volta ampiamente supportato estensione a HTTP). Delta-V aggiunge il controllo delle versioni a WebDAV ed è descritto in RFC 3253 .

score 1 · Answer 4

Un modo relativamente semplice consiste nell'incrementare un id di revisione ad ogni salvataggio e salvare il nuovo documento xml sotto il nuovo id di revisione.

tabella: documenti

doc_id | name          | current_revision
   1   | Shopping List |       5

tabella: doc_revisions

doc_id | revision | timestamp | xml_blob
  1    |    1     | 2012...   |
  1    |    2     | 2012...   |
  1    |    3     | 2012...   |
  1    |    4     | 2012...   |
  1    |    5     | 2012...   |

Si potrebbe anche considerare di memorizzare i file xml separatamente nel file system. Puoi modificare la tabella doc_revisions con un URL / percorso al file anziché un blob. Ciò consentirà al db di gestire volumi molto più elevati su un singolo server, perché il database non sarà fisicamente grande (è possibile spostare i documenti su un server diverso) e si prenderà il carico di recupero del documento dal server db.

Personalmente, non memorizzerei le differenze di file. Piuttosto, memorizzerei la nuova revisione completa del file ogni volta. Lo spazio di archiviazione è economico e non è necessario complicare le cose. La funzionalità 'diff' potrebbe essere implementata in un secondo momento se alla fine si rivelasse necessario veramente . Se memorizzi diff, tieni presente che potrebbe introdurre una serie di complessità inaspettate, ad esempio se devi cercare nel testo dei documenti.

score 1 · Answer 5

Perché non imitare un log del database?

Fondamentalmente, le modifiche sono contrassegnate cronologicamente come transazioni. Per un DB del documento, una transazione consisterebbe in un blob differenziale + timestamp anziché in una riga di tabella, ma il concetto funziona allo stesso modo. Praticamente come funzionano i sistemi di controllo delle versioni.

Per mantenere le cose scattanti mantenere una copia cache della versione corrente. Se qualcuno ha bisogno di tornare indietro nel tempo, può eseguire il rollback (cioè invertire) le transazioni finché non raggiungono lo storico richiesto di cui hanno bisogno. L'idea è che la copia cache non cambia fino a quando non viene eseguita un'operazione di salvataggio.

Per mantenere la coerenza, devi anche prendere in considerazione i rollback. Seguendo quello che ho già descritto, diciamo che l'utente torna indietro 5 versioni. 5 transazioni verrebbero applicate all'indietro in ordine cronologico inverso alla versione corrente ma quando tale stato viene salvato, la transazione viene memorizzata come diff da quello stato rispetto alla versione corrente.

Fondamentalmente, la cronologia non viene mai riscritta, solo riutilizzata per creare nuove versioni.