Formas de versionar documentos generados por el usuario

Tengo un documento en línea que esencialmente se almacena en la base de datos como una cadena XML.

Estoy pensando en una forma de implementar versiones del documento para el usuario. Para que el usuario pueda volver a las versiones anteriores del documento.

actualizar En mi caso es una aplicación web con cientos de miles de usuarios. Un usuario puede almacenar una cantidad ilimitada de documentos. El XML para el documento se almacena en el campo de blobs de MySQL, por lo que no es pequeño. Eventualmente necesito limitar los límites de alguna manera, pero ese es un tema diferente en conjunto.

¿Hay una forma estándar de abordar esto? ¿Debo almacenar solo las diferencias entre versiones? ¿Qué otras cosas debo tener en cuenta?

¿Por qué no usar un repositorio de control de código fuente? Ocupará menos espacio de almacenamiento, hará todo lo que desee actualmente y le permitirá ampliar fácilmente el concepto a ramas, etiquetas, etc., todo lo que obtiene de un RCS. ¿Por qué reinventar la rueda?

Como está haciendo esto en una base de datos, la forma más fácil de versionar su cadena XML sería crear una nueva tabla de Historial con las siguientes columnas:

• ID de historia
• Nueva cadena XML (columna opcional)
• Cadena XML antigua
• Insertar marca de tiempo

Inserte una fila en esta tabla de Historial antes de actualizar la fila en la tabla de cadenas XML.

¿Hay una forma estándar de abordar esto?

Para un enfoque basado en estándares, eche un vistazo a la extensión Delta-V a WebDAV (una extensión ampliamente admitida a HTTP). Delta-V agrega versiones a WebDAV y se describe en RFC 3253 .

Una forma relativamente simple es incrementar una identificación de revisión en cada guardado y guardar el nuevo documento xml bajo esa nueva identificación de revisión.

tabla: docs

doc_id | name          | current_revision
   1   | Shopping List |       5         

tabla: doc_revisions

doc_id | revision | timestamp | xml_blob
  1    |    1     | 2012...   |
  1    |    2     | 2012...   |
  1    |    3     | 2012...   |
  1    |    4     | 2012...   |
  1    |    5     | 2012...   |

También puede considerar almacenar los archivos xml por separado en el sistema de archivos. Puede modificar la tabla doc_revisions con una URL / ruta al archivo en lugar de un blob. Eso permitirá que su base de datos maneje volúmenes mucho más altos en un solo servidor porque la base de datos no será físicamente tan grande (podría mover los documentos a un servidor diferente) y estaría quitando la carga de recuperación de documentos del servidor de base de datos.

Personalmente, no almacenaría las diferencias de archivo. Más bien, almacenaría la nueva revisión completa del archivo cada vez. El almacenamiento es barato y no es necesario complicar las cosas. La funcionalidad 'diff' podría implementarse más adelante si finalmente resulta que realmente la necesita. Si almacena diffs, tenga en cuenta que podría introducir un montón de complejidades inesperadas, por ejemplo, si necesita buscar el texto de los documentos.

¿Por qué no imitar un registro de base de datos?

Básicamente, los cambios se marcan cronológicamente como transacciones. Para una base de datos de documentos, una transacción consistiría en una marca de tiempo y una marca de tiempo diffs en lugar de una entrada de fila de tabla, pero el concepto funciona igual. Prácticamente de la misma manera que funcionan los sistemas de control de versiones.

Para mantener las cosas ágiles, mantenga una copia en caché de la versión actual. Si alguien necesita retroceder en el tiempo, puede revertir (es decir, revertir) las transacciones hasta que alcancen el historial solicitado. La idea es que la copia en caché no cambia hasta que se realiza una operación de guardar.

Para mantener la coherencia, también debe tener en cuenta las reversiones. Siguiendo lo que ya describí, digamos que el usuario retrocede 5 versiones. 5 transacciones se aplicarían inversamente en orden cronológico inverso a la versión actual, pero cuando se guarda ese estado, la transacción se almacena como una diferencia de ese estado en comparación con la versión actual.

Básicamente, la historia nunca se reescribe, solo se reutiliza para crear nuevas versiones.