synchronization - offline database node

Couchdb sincronización fuera de línea en línea

Question

Estoy construyendo una aplicación .NET que tendrá una instancia CouchDB local donde se escriben todos los datos, y un CouchDB central donde el CouchDB local está sincronizado. La dificultad es que habrá múltiples clientes que se sincronizarán con la base de datos en diferentes puntos (y podrían editar datos existentes, creando conflictos). La conexión a Internet no será coherente, por lo que la mayoría de los datos se crearán / editarán sin conexión.

Creo que CouchDB maneja esto de forma inherente, sin embargo, tengo dificultades para determinar si debo trabajar con la funcionalidad _cambios o _replicator, o una combinación. Agradecería mucho algunos consejos sobre cómo manejar este escenario.

Answer 1

Couchdb detectará conflictos por usted, sin embargo, le deja a usted la responsabilidad de manejar esos conflictos. Aquí hay detalles sobre el modelo de conflicto de couchdb y algunas formas de diseñar su aplicación para la replicación.

_changes no es una buena forma de replicar porque solo proporciona cambios recientes a un documento dado. Por lo tanto, si se replica utilizando un feed de cambios en una base de datos recién creada, perderá algunos de los cambios más antiguos. Y tendrá que realizar manualmente las operaciones como actualizar documentos que _replication hace por usted. _replication también tiene algunas _replication como la posibilidad de crear una base de datos de destino si aún no existe.

Incluso si está escuchando continuous alimentación continuous de cambios, no se garantiza que se devolverán todas las actualizaciones del documento.

Devuelve una lista ordenada de cambios realizados a los documentos en la base de datos, en el orden de tiempo de la solicitud, se puede obtener desde el recurso _changes de la base de datos. Solo se garantiza que se proporcionará el cambio más reciente para un documento determinado, por ejemplo, si un documento tiene campos agregados, y luego se elimina, un cliente API que verifica cambios no necesariamente recibirá el estado intermedio de los documentos agregados.

Entonces, la replication es el camino a seguir si planea replicar los datos en varios dispositivos.