versioning - tipos - git version control
Estrategia de versionamiento de CouchDB (4)
¿Cuál es el estado de negocios de estos documentos, especialmente legal? He trabajado en situaciones en las que su propuesta no sería apropiada desde un punto de vista empresarial, debido a la necesidad de demostrar 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 el cumplimiento de la mostaza.
Si, como usted dice, los cambios en los documentos no son frecuentes, entonces no va a ahorrar mucho espacio en el disco al almacenar 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.
La siguiente sería una estrategia viable para implementar el control de versiones (usando "ejemplo" como tipo de documento de muestra):
Tenga un documento original donde el campo de tipo se llame example_original.
Todos los cambios subsiguientes en el documento tienen el tipo example_change y el id del example_original document como una clave. El cambio también llevaría una marca de tiempo.
Mantenga un documento con el tipo example_current que sea el resultado de example_original con todos los example_change "aplicados". Un nuevo documento example_change se aplicaría automáticamente a este documento.
Encontrar una versión específica consistiría en recuperar el documento example_original y aplicar los cambios deseados (en su mayoría hasta una cierta marca de tiempo, pero también podría ser una serie de cambios).
Debo mencionar que mi caso de uso implicará un número limitado de cambios al original. La mayoría de las actualizaciones consistirán en nuevos documentos originales. Si bien este es mi caso de uso actual, también estaría interesado en los problemas que surgirían si se produjeran muchos cambios.
¿Qué ventajas y desventajas ves en este enfoque?
Mi primera preocupación es: al "obtener" una versión determinada, ¿puede aplicar los cambios al original sin modificar la base de datos?
¿Alguna vez necesitarás borrar algo del historial? ¿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 lo usé. Me gustaría un enfoque más simple:
Cuando creas un documento, asignas un UUID. No use el nombre o se encontrará con problemas durante las operaciones de cambio de nombre. Agrega 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 histórico" por documento permite una navegación más rápida del historial, pero los punteros principales son más "seguros" (ya que no se pueden crear fácilmente estructuras ilegales con ellos)
Cuando cree una nueva revisión, reutilice el UUID y asigne una versión nueva y única. Actualice el documento histórico o el puntero padre.
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.
Una estrategia para crear versiones con CouchDB es NO compactar nunca la base de datos que contiene los documentos para los que necesita mantener un historial completo. Todavía podría compactar otras bases de datos. Esta estrategia simple funciona de manera inmediata con una estrategia de resolución de conflictos de edición.
La eliminación de un documento se puede hacer escribiendo una nueva versión sin contenido, pero con un conjunto de propiedades eliminadas.
Las sucursales 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 contiene una copia completa del documento, pero uno podría pensar que las optimizaciones del motor CouchDB podrían almacenar deltas algún día.
- 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 sucursales de documentos, pero considerando la naturaleza de CouchDB como una base de datos de documentos, esto es una posibilidad razonable, pero a largo plazo.
Versión simple de documentos con CouchDB
El enfoque de creación de versiones como adjuntos descrito en este artículo debe cumplir con los requisitos de la mayoría de las personas para la creación de versiones.