¿Cómo implementaría un sistema de control de revisiones para sus modelos en su paradigma de db preferido?

Question

Descubrí que RCS for models es un problema interesante de resolver en el contexto de la persistencia de los datos. Son varias las soluciones que utilizan el django ORM para lograr esto django-reversion y AuditTrail, cada uno de los cuales propone su propia manera de hacerlo.

Aquí es el modelo (en formato django-modelo similar) que me gustaría tener revisiones:

class Page(Model): 

    title = CharField() 
    content = TextField() 
    tags = ManyToMany(Tag) 
    authors = ManyToMany(Author) 

• Cada revisión debe ser anotado con una fecha , un número revisión , un comentario y el usuario que hizo la modificación.

¿Cómo lo harías en tu preferencia db (Mongo, neo4j, CouchDb, GAE Datastore)?

Por favor, publique solo un ejemplo de modelos de RCS por publicación.

No estoy pidiendo un código completo (¿tal vez una explicación es suficiente?) Pero es suficiente para ver cómo se puede abordar este problema en cada tipo de base de datos.

Answer 1

En CouchDB esto es bastante sencillo. Cada elemento en el DB tiene un _id y un _rev. Por lo tanto, no necesita un número de revisión por separado. Probablemente haría esto entonces. Asigna a cada elemento un número systemrev. Este número sería un enlace a otro registro de BD que contiene la fecha, el comentario y el usuario para esa revisión.

Ejemplos:

artículo realiza un seguimiento de:

{ 
    _id: "1231223klkj123", 
    _rev: "4-1231223klkj123", 
    systemRev: "192hjk8fhkj123", 
    foo: "bar", 
    fooarray: ["bar1", "bar2", bar3"] 
} 

y luego crear un registro de revisión independiente:

{ 
    _id: "192hjk8fhkj123", 
    _rev: "2-192hjk8fhkj123", 
    user: "John", 
    comment: "What I did yesterday", 
    date: "1/1/2010", 
    tags: ["C# edits", "bug fixes"] 
} 

Me parece muy elegante ....

Answer 2

En primer lugar, si está utilizando CouchDB, no use el campo _rev.

¿Por qué? Las viejas revisiones se pierden cuando se compacta una base de datos.

compactación reescribe el archivo de base de datos, eliminación de revisiones de documentos obsoletos y documentos eliminados.

CouchDB wiki - Compaction page

Hay un par de posibles soluciones:

1. Mantener la versión actual y la edad en la misma base de datos. Agregue un campo de revisión adicional para determinar la diferencia entre las revisiones actuales y anteriores.
2. Almacenar revisiones antiguas en una base de datos separada.Cuando se agrega una nueva revisión a la base de datos "actual", el documento de revisión anterior se puede eliminar e insertar en la base de datos "revisiones".

¿Cuál es la mejor? Depende de cómo se accederá a sus datos. Si puede consultar las revisiones anteriores independientemente de las revisiones actuales, entonces almacenar el documento en 2 bases de datos diferentes le dará algunos beneficios de rendimiento.