CouchDB strategia di controllo delle versioni

Question

avrebbero i seguenti essere una strategia praticabile per l'attuazione delle versioni (usando "esempio", come un tipo di documento del campione):

Avere un documento originale in cui il campo tipo è denominato example_original.

Le modifiche successive apportate al documento sono tutte di tipo example_change e l'id del documento original_original come chiave. Il cambiamento porterebbe anche un timestamp.

Mantieni un documento con tipo example_current che è il risultato di example_original con tutto example_change "applicato". Un nuovo documento example_change verrà automaticamente applicato a questo documento.

Trovare una versione specifica consiste nel recuperare il documento original_original e applicare le modifiche desiderate (principalmente fino a un determinato timestamp, ma potrebbe anche essere un numero di modifiche).

Devo dire che il mio caso d'uso comporterà un numero limitato di modifiche all'originale. La maggior parte degli aggiornamenti consisterà in nuovi documenti originali. Anche se questo è il mio attuale caso d'uso, sarei interessato anche a problemi che si verificherebbero se fossero apportate numerose modifiche.

Quali pro e contro vedi in questo approccio?

Answer 1

La mia prima preoccupazione è: quando si "ottiene" una determinata versione, è possibile applicare le modifiche all'originale senza modificare il database?

Hai mai bisogno di cancellare qualcosa dalla cronologia? Sei proprio sicuro? Davvero, davvero sicuro? Che ne dici di rami?

Tutto sommato, sembra una strategia complessa. Tieni presente che ho sentito parlare di CouchDB ma non l'ho mai usato. Mi piacerebbe andare per un approccio più semplice:

1. Quando si crea un documento, si assegna un UUID. Non usare il nome o incontrerai dei problemi durante le operazioni di rinomina. Aggiungi un campo versione che legge "1". Creare un secondo documento che contiene un elenco di documenti con lo stesso UUID o aggiungere un puntatore "padre" al primo documento.

   Avere un "documento di storia" per documento consente una navigazione più veloce della cronologia ma i puntatori principali sono più "sicuri" (dato che non è possibile creare facilmente strutture illegali con essi).

2. Quando si crea una nuova revisione, riutilizzare l'UUID e assegnare una nuova versione unica. Aggiorna il documento cronologico o il puntatore genitore.

Questa strategia è abbastanza semplice da implementare e consente tutti i tipi di flessibilità in seguito. È possibile cancellare facilmente parti della cronologia, rinominare è semplice e creare rami.

Answer 2

Qual è lo stato commerciale di questi documenti, in particolare legale? Ho lavorato in situazioni in cui la tua proposta non sarebbe appropriata da un business in prospettiva, a causa della necessità di dimostrare che il documento presentato come v.3 è in realtà la versione 3 del documento. L'applicazione dinamica dei delta non taglierebbe la senape di conformità.

Se, come dici tu, le modifiche ai documenti non sono frequenti, non stai risparmiando molto spazio su disco memorizzando delta anziché documenti interi. La memorizzazione di interi documenti consente anche la previsione affidabile del tempo di recupero per qualsiasi documento. Riduce anche la complessità del processo di recupero.

Answer 3

Una strategia per il controllo delle versioni con CouchDB è NON compattare mai il database che contiene i documenti per i quali è necessario conservare una cronologia completa. Potresti ancora compattare altri database. Questa semplice strategia funziona oggi senza problemi con una strategia di risoluzione dei conflitti di modifica.

L'eliminazione di un documento può essere eseguita scrivendo una nuova versione senza contenuto ma una serie di proprietà eliminate.

I rami non possono essere eseguiti in questo modo perché il meccanismo di controllo delle versioni offre un singolo thread di revisioni.

Ora per il possibile futuro di CouchDB:

• Oggi ogni revisione tiene una copia completa del documento, ma si potrebbe pensare che ottimizzazioni del motore di CouchDB potrebbe un delta Store Day.
• È anche possibile che in futuro CouchDB offra un'API per impedire la compattazione di determinati tipi di documento. Ciò consentirebbe di mantenere tutti i documenti nello stesso database. Questa sarebbe una patch facile per CouchDB.
• Questa strategia consente la gestione di filiali di documenti ma considerando la natura di CouchDB come un database di documenti, si tratta di una possibilità ragionevole, ma a lungo termine.

Answer 4

Simple Document Versioning with CouchDB

Il controllo delle versioni come allegati approccio descritto in questo articolo dovrebbe soddisfare esigenze di molte persone per il controllo delle versioni.