strategia di controllo delle versioni CouchDB

Question

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

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

Le modifiche successive al documento tutti hanno il tipo example_change e l'id del documento di example_original come chiave. Il cambiamento sarebbe anche portare un timestamp.

Tenere un documento con il tipo example_current che è il risultato di example_original con tutto example_change "applicata". Un nuovo documento example_change sarebbe automaticamente essere applicato a questo documento.

Trovare una versione specifica consisterebbe nel recupero doc example_original e applicando le modifiche desiderate (per lo più fino a un certo timestamp, ma potrebbe anche essere una serie di modifiche).

Devo dire che il mio caso d'uso coinvolgerà un numero limitato di modifiche all'originale. La maggior parte dei aggiornamenti saranno costituiti da nuovi documenti originali. Mentre questo è il mio attuale impiego a caso vorrei anche essere interessati a questioni che risulterebbe se molti cambiamenti sono stati coinvolti.

Quali pro e contro vedete in questo approccio?

Answer 1

La mia prima preoccupazione è: Quando "ottenere" una certa versione, si può applicare le modifiche a quello originale senza modificare il database

?

Vuoi mai bisogno di cancellare qualcosa dalla storia? Sei davvero sicuro? Davvero, davvero sicuro? Che ne dite di rami?

Tutto sommato, questo appare come una strategia complessa. Tenete a mente che ho sentito parlare di CouchDB ma mai usata. Mi piacerebbe andare per un approccio più semplice:

1. Quando si crea un documento, si assegna un UUID. Non utilizzare il nome o si incorrerà in problemi durante le operazioni di ridenominazione. Aggiungere 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" per il primo documento.

   Avere un "documento storico" per documento consente una navigazione più veloce della storia, ma genitore puntatori sono più "sicuro" (dal momento che non è possibile creare facilmente strutture illegali con loro).

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

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

Answer 2

semplice documento Versioning con CouchDB

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

Answer 3

Qual è lo stato di business di questi documenti, in particolare legale? Ho lavorato in situazioni in cui la vostra proposta non sarebbe appropriato un business persepctive, a causa di un bisogno di dimostrare che il documento presentato come v.3 è in realtà la versione 3 del documento. Dinamicamente delta applicano non sarebbe tagliare la senape di conformità.

Se, come dici tu, le modifiche ai documenti ae infrequente, allora non si ha intenzione di essere il risparmio di spazio su disco per la memorizzazione di delta, invece di interi documenti. Memorizzazione di interi documenti permette anche per la previsione affidabile del tempo di recupero per qualsiasi documento. Si riduce anche la complessità del processo di recupero.

Answer 4

Una strategia per il controllo delle versioni con CouchDB è quello di non sempre compatta il database che contiene i documenti per i quali è necessario tenere una storia completa. Si potrebbe ancora compatti altri database. Questa semplice strategia funziona oggi, fuori dalla scatola, con una strategia di modifica della risoluzione dei conflitti.

Eliminazione di un documento potrebbe essere fatto scrivendo una nuova versione senza alcun contenuto, ma un insieme di proprietà cancellato.

rami non può essere fatto in questo modo perché il meccanismo delle versioni offre un singolo filo di revisioni.

Ora, per il possibile futuro di CouchDB:

• Oggi ogni revisione contiene una copia completa del documento, ma si potrebbe pensare che le ottimizzazioni del motore CouchDB potrebbe un giorno negozio delta.
• E 'anche possibile che in futuro CouchDB offrirebbe un'API per prevenire la compattazione di alcuni tipi di documenti. Ciò consentirebbe di mantenere tutti i documenti nello stesso database. Questo sarebbe un cerotto facile da CouchDB.
• Questa strategia fa consentire la gestione delle filiali del documento ma considerando la natura di CouchDB come un database di documenti, questa è una cosa di una ragionevole, ma a lungo termine, possibilità.