estrategia de control de versiones CouchDB

Question

¿La siguiente es una estrategia viable para la implementación de versiones (usando "ejemplo" como un tipo de documento muestra):

Tener un documento original en el campo de tipo se denomina example_original.

Los cambios posteriores en el documento todos tienen example_change tipo y el ID del documento example_original como clave. El cambio también podría llevar a una marca de tiempo.

Mantener un documento con el tipo example_current que es el resultado de example_original con toda example_change "aplicado". Un nuevo documento example_change automáticamente se aplicaría a este documento.

Encontrar una versión específica consistiría en la recuperación de la doc example_original y aplicar los cambios deseados (en su mayoría hasta una cierta marca de tiempo, pero también podría ser un número de cambios).

Debo mencionar que mi caso de uso implicará un número limitado de cambios en el original. La mayoría de los cambios consistirán en nuevos documentos originales. Si bien este es mi caso de uso corriente I también estaría interesado en los temas que se produciría si muchos cambios, donde los involucrados.

¿Qué pros y contras ves en este enfoque?

Answer 1

Mi primera preocupación es: Cuando "conseguir" una determinada versión, se puede aplicar los cambios en el original sin modificar la base de datos

?

¿Alguna vez tenga que eliminar algo de la historia? ¿Estas realmente seguro? Realmente, realmente seguro? ¿Qué hay de las ramas?

Con todo, esto parece una estrategia compleja. Tenga en cuenta que he oído hablar de CouchDB pero nunca utilizado. Me gustaría ir a un enfoque más simple:

1. Cuando se crea un documento, se asigna un UUID. No utilice el nombre o se encontrará con problemas durante las operaciones de cambio de nombre. Añadir un campo de versión que dice "1". Cree un segundo documento que contiene una lista de documentos con el mismo UUID o añadir un puntero "padre" al primer documento.

   Tener un "documento de la historia" por documento permite una navegación más rápida de la historia, pero los padres son más punteros "seguro" (ya que no se puede crear fácilmente estructuras ilegales con ellos).

2. Cuando se crea una nueva revisión, vuelve a utilizar el UUID y asignar una nueva versión, única. Actualizar el documento de la historia o el puntero padre.

Esta estrategia es muy simple de implementar y permite todo tipo de flexibilidad más adelante. Puede borrar partes de la historia fácilmente, cambiar el nombre es simple, y puede crear ramas.

Answer 2

simple de versiones de documentos con CouchDB

El control de versiones como archivos adjuntos enfoque descrito en este artículo debe adaptarse a las necesidades de la mayoría de la gente del control de versiones.

Answer 3

¿Cuál es el estado del negocio de estos documentos, sobre todo legal? He trabajado en situaciones en las que su propuesta no sería apropiado desde un persepctive negocio, debido a la necesidad de demostrar que el documento presentado como la versión 3 es realmente la versión 3 del documento. Dinámicamente deltas que solicitan no cortar la mostaza cumplimiento.

Si, como usted dice, cambios en los documentos ae infrecuentes, entonces no va a estar ahorrando mucho espacio en disco mediante el almacenamiento de los deltas en lugar de documentos completos. El almacenamiento de documentos enteros también permite la predicción fiable del tiempo de recuperación para cualquier documento. También reduce la complejidad del proceso de recuperación.

Answer 4

Una estrategia de control de versiones con CouchDB es no siempre compacta la base de datos que contiene los documentos de los que usted necesita para tener una historia completa. Aún se podía compactos otras bases de datos. Esta simple estrategia funciona hoy fuera de la caja con una estrategia de resolución de conflictos de edición.

Eliminación de un documento que se podría hacer al escribir una nueva versión sin contenido, sino un conjunto de propiedades eliminado.

Las ramas no se puede hacer de esta manera porque el mecanismo de control de versiones ofrece un único hilo de las revisiones.

Ahora, para el posible futuro de CouchDB:

• Hoy en día cada revisión contiene una copia completa del documento, pero se podría pensar que las optimizaciones del motor CouchDB podía almacenar los deltas de un día.
• También es posible que en el futuro CouchDB ofrecería una API para evitar la compactación de ciertos tipos de documentos. Esto permitiría mantener todos los documentos en la misma base de datos. Esto sería un parche fácil de CouchDB.
• Esta estrategia hace que el manejo de las ramas de documentos pero teniendo en cuenta la naturaleza de CouchDB como una base de datos documental, esto es algo de un razonable, sin embargo, a largo plazo, posibilidad.