CouchDB stratégie de versionnage

Question

Est-ce que ce qui suit une stratégie viable pour la mise en œuvre versioning (en utilisant "exemple" comme un type de document d'exemple):

Avoir un document original où le champ de type est nommé example_original.

Des modifications ultérieures du document ont tous types example_change et l'identifiant du document example_original comme une clé. Le changement effectuerez également un horodatage.

Gardez un doc avec le type example_current qui est le résultat de example_original avec tous example_change « appliquée ». Un nouveau document de example_change serait automatiquement appliquée à ce document.

Trouver une version spécifique consisterait à récupérer le example_original doc et appliquer les modifications souhaitées (la plupart du temps jusqu'à un certain horodatage, mais il pourrait aussi être un certain nombre de changements).

Je dois mentionner que mon cas d'utilisation implique un nombre limité de modifications à l'original. La plupart des mises à jour consisteront de nouveaux documents originaux. Bien que ce soit mon cas d'utilisation actuelle Je serais également intéressé par les questions qui résulterait de nombreux changements étaient impliqués.

Quels avantages et inconvénients voyez-vous dans cette approche?

Answer 1

Mon premier souci est: Quand « obtenir » une certaine version, pouvez-vous appliquer les modifications apportées à l'original sans modifier la base de données

?

Voulez-vous jamais besoin de supprimer quelque chose de l'histoire? Êtes-vous vraiment sûr? Vraiment, vraiment sûr? Que diriez-vous des branches?

Dans l'ensemble, cela ressemble à une stratégie complexe. Gardez à l'esprit que je l'ai entendu parler de CouchDB, mais jamais utilisé. Je vais pour une approche plus simple:

1. Lorsque vous créez un document, vous attribuez un UUID. Ne pas utiliser le nom ou vous rencontrez des problèmes lors des opérations de changement de nom. Ajouter un champ de version qui lit « 1 ». Créer un second document qui contient une liste de documents avec le même UUID ou ajouter un pointeur « parent » au premier document.

   Avoir un « document historique » par document permet une navigation plus rapide de l'histoire, mais les pointeurs parents sont plus « sûrs » (puisque vous ne pouvez pas créer facilement des structures illégales avec eux).

2. Lorsque vous créez une nouvelle révision, réutiliser l'UUID et d'assigner une nouvelle version unique. Mettre à jour le document de l'histoire ou le pointeur parent.

Cette stratégie est assez simple à mettre en œuvre et permet plus tard toutes sortes de flexibilité. Vous pouvez effacer des parties de l'histoire facilement, renommer est simple, et vous pouvez créer des branches.

Answer 2

simple document Versioning avec CouchDB

Le versioning comme pièces jointes approche décrite dans cet article devrait répondre aux besoins de la plupart des gens pour versioning.

Answer 3

Quel est le statut commercial de ces documents, en particulier juridique? Je travaille dans des situations où votre proposition ne serait pas approprié d'un persepctive d'affaires, en raison d'un besoin de prouver que le document présenté comme v.3 est vraiment la version 3 du document. Dynamiquement application deltas ne couperaient pas la moutarde de la conformité.

Si, comme vous le dites, les modifications des documents ae peu fréquents, alors vous n'allez économiser l'espace disque en stockant deltas au lieu de documents entiers. Le stockage des documents entiers permet également la prévision fiable du temps de récupération pour tout document. Elle réduit également la complexité du processus de récupération.

Answer 4

Une stratégie de versionnage avec CouchDB est à la base de données jamais compact qui contient les documents dont vous avez besoin de garder un historique complet. Vous pourriez encore d'autres bases de données compactes. Cette stratégie simple fonctionne aujourd'hui hors de la boîte avec une stratégie de conflit de modifier la résolution.

Suppression d'un document qui pourrait être fait en écrivant une nouvelle version sans contenu, mais un ensemble de propriétés supprimés.

Les branches ne peuvent se faire de cette façon parce que le mécanisme de versionnage offre un fil de révisions.

pour l'avenir possible de CouchDB:

• Aujourd'hui, chaque révision contient une copie complète du document, mais on pourrait penser que l'optimisation du moteur CouchDB pourrait un deltas de magasin de jour.
• Il est également possible que dans le futur CouchDB offrirait une API pour éviter le compactage de certains types de documents. Cela permettrait de conserver tous les documents dans la même base de données. Ce serait une tache facile à CouchDB.
• Cette stratégie ne permet la gestion des branches de documents, mais compte tenu de la nature de CouchDB comme base de données de documents, c'est quelque chose d'un raisonnable, mais à long terme, possibilité.