estrategia de control de versiones CouchDB

Question

estaría el siguiente ser 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 subsiguientes en el documento tienen todos el tipo example_change y el id del documento example_original como clave. El cambio también llevaría una marca de tiempo.

Guarde un documento con el tipo example_current que es el resultado de example_original con todo example_change "applied". Se aplicará automáticamente un nuevo documento de cambio de ejemplo a este documento.

Encontrar una versión específica consistiría en recuperar el documento original_original y aplicar los cambios deseados (principalmente hasta una determinada marca de tiempo, pero también podría ser una cantidad de cambios).

Debo mencionar que mi caso de uso implicará un número limitado de cambios en el original. La mayoría de las actualizaciones consistirán en nuevos documentos originales. Si bien este es mi caso de uso actual, también me interesarían los problemas que podrían surgir si se producen muchos cambios.

¿Qué pros y contras ves en este enfoque?

Answer 1

Mi primera preocupación es: cuando "consigas" una cierta versión, ¿puedes aplicar los cambios al original sin modificar la base de datos?

¿Alguna vez tendrá que eliminar algo del historial? ¿Estas realmente seguro? De verdad, ¿de verdad? ¿Qué hay de las ramas?

En general, esto parece una estrategia compleja. Tenga en cuenta que he oído hablar de CouchDB pero nunca lo he usado. Me gustaría un enfoque más simple:

1. Cuando crea un documento, asigna un UUID. No use el nombre o tendrá problemas durante las operaciones de cambio de nombre. Agregue un campo de versión que dice "1". Cree un segundo documento que contenga una lista de documentos con el mismo UUID o agregue un puntero "principal" al primer documento.

   Tener un "documento de historial" por documento permite una navegación más rápida del historial, pero los punteros de los padres son más "seguros" (ya que no es fácil crear estructuras ilegales con ellos).

2. Cuando crea una nueva revisión, reutilice el UUID y asigne una nueva versión única. Actualice el documento de historial o el puntero principal.

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

Answer 2

¿Cuál es el estado comercial de estos documentos, especialmente los legales? He trabajado en situaciones en las que su propuesta no sería apropiada para una empresa perseverante, debido a la necesidad de probar que el documento presentado como v.3 realmente es la versión 3 del documento. La aplicación dinámica de deltas no cortaría la mostaza de cumplimiento.

Si, como dices, los cambios en los documentos ae son poco frecuentes, entonces no vas a ahorrar mucho espacio de disco almacenando deltas en lugar de documentos completos. El almacenamiento de documentos completos también permite la predicción confiable del tiempo de recuperación de cualquier documento. También reduce la complejidad del proceso de recuperación.

Answer 3

Una estrategia para versionar con CouchDB es NO compactar nunca la base de datos que contiene los documentos para los cuales necesita mantener un historial completo. Aún podría compactar otras bases de datos. Esta estrategia simple funciona hoy en día con una estrategia de edición de resolución de conflictos.

Eliminar un documento podría hacerse escribiendo una nueva versión sin contenido pero con un conjunto de propiedades eliminado.

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

Ahora, para el posible futuro de CouchDB:

• Hoy en día cada revisión mantiene una copia completa del documento, pero se podría pensar que las optimizaciones del motor CouchDB podrían un día deltas de tiendas.
• También es posible que en el futuro CouchDB ofrezca 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 para CouchDB.
• Esta estrategia permite la administración de las ramas de documentos, pero considerando la naturaleza de CouchDB como una base de datos de documentos, esta es una posibilidad razonable, pero a largo plazo.

Answer 4

Simple Document Versioning with 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.