Este dilema se puede abordar de diferentes maneras, pero en este caso te enseñamos la resolución más completa en nuestra opinión.
Solución:
La primera gran pregunta al sumergirse en esto es “¿Cómo quieres almacenar los conjuntos de cambios?”?
- ¿Diferencias?
- ¿Copias completas de discos?
Mi enfoque personal sería almacenar diferencias. Debido a que la visualización de estas diferencias es realmente una acción especial, colocaría las diferencias en una colección de “historial” diferente.
Usaría la colección diferente para ahorrar espacio en la memoria. Por lo general, no desea un historial completo para una consulta simple. Entonces, al mantener el historial fuera del objeto, también puede mantenerlo fuera de la memoria de acceso común cuando se consultan esos datos.
Para facilitarme la vida, haría que un documento de historial contuviera un diccionario de diferencias con marca de tiempo. Algo como esto:
_id : "id of address book record",
changes :
1234567 : "city" : "Omaha", "state" : "Nebraska" ,
1234568 : "city" : "Kansas City", "state" : "Missouri"
Para facilitarme la vida, lo convertiría en parte de mis DataObjects (EntityWrapper, lo que sea) que uso para acceder a mis datos. Por lo general, estos objetos tienen algún tipo de historial, por lo que puede anular fácilmente el save() método para hacer este cambio al mismo tiempo.
ACTUALIZACIÓN: 2015-10
Parece que ahora hay una especificación para manejar las diferencias JSON. Esta parece una forma más robusta de almacenar las diferencias/cambios.
Hay un esquema de versiones llamado “Vermongo” que aborda algunos aspectos que no se han tratado en las otras respuestas.
Uno de estos problemas son las actualizaciones simultáneas, otro es la eliminación de documentos.
Vermongo almacena copias completas de documentos en una colección oculta. Para algunos casos de uso, esto puede causar demasiada sobrecarga, pero creo que también simplifica muchas cosas.
https://github.com/thiloplanz/v7files/wiki/Vermongo
Aquí hay otra solución que usa un solo documento para la versión actual y todas las versiones anteriores:
_id: ObjectId("..."),
data: [
vid: 1, content: "foo" ,
vid: 2, content: "bar"
]
data contiene todos versiones. los data array es ordenadolas nuevas versiones solo obtendrán $pushed hasta el final de la array. data.vid es el id de la versión, que es un número creciente.
Obtenga la versión más reciente:
find(
"_id":ObjectId("...") ,
"data": $slice:-1
)
Obtener una versión específica por vid:
find(
"_id":ObjectId("...") ,
"data": $elemMatch: "vid":1
)
Devuelve solo los campos especificados:
find(
"_id":ObjectId("...") ,
"data": $elemMatch: "vid":1 , "data.content":1
)
Insertar nueva versión: (y evitar la inserción/actualización simultánea)
update(
"_id":ObjectId("..."),
$and:[
"data.vid": $not: $gt:2 ,
"data.vid":2
]
,
$push: "data": "vid":3, "content":"baz"
)
2 es el vid de la versión actual más reciente y 3 es la nueva versión que se inserta. Porque necesita la versión más reciente vides fácil obtener la próxima versión vid: nextVID = oldVID + 1.
los $and condición asegurará que 2 es el último vid.
De esta manera no hay necesidad de un índice único, pero la lógica de la aplicación tiene que encargarse de incrementar el vid en inserto.
Eliminar una versión específica:
update(
"_id":ObjectId("...") ,
$pull: "data": "vid":2
)
¡Eso es todo!
(recuerda el límite de 16 MB por documento)
Reseñas y valoraciones
Nos encantaría que puedieras recomendar esta división si te fue útil.