2012-08-23 12 views
10

Estoy tratando de evaluar usando IndexedDB para resolver el problema sin conexión. Se llenaría con datos almacenados actualmente en una base de datos MongoDB (como está).Sincronizando datos del servidor MongoDB a un almacén local IndexedDB

Una vez que los datos se almacenan en IndexedDB, se pueden cambiar en el servidor MongoDB y necesito propagar esos cambios. ¿Hay algún marco o biblioteca existente para hacer algo como esto para Mongo. Ya sé sobre CouchDB/PouchDB y no estoy explorando esos dos.

+0

Usted debe ver si ninguno de los códigos de meteoros es relevante. – ranman

+0

Muy interesante, gracias. Posiblemente una solución a mi problema real: escribir una aplicación fuera de línea. Debe hacer de esto una respuesta para que pueda darle los puntos si resuelve mi problema –

+0

Resulta que no se admite el escenario sin conexión completo (inicio de sesión sin conexión + cambios + sincronización al servidor cuando vuelva a estar en línea): https: // groups. google.com/d/topic/meteor-core/ZVj6RFbKDq0/discussion –

Respuesta

0

No he trabajado con IndexDB, pero el problema de diseño no es poco común. Mi comprensión de su aplicación es que cuando el cliente realiza la conexión a MongoDB, retira un conjunto de documentos para su almacenamiento local y se desconecta. El cliente entonces puede hacer cosas localmente (no conectado al servidor de datos), y luego hacer subir los cambios.

La forma en que veo que usted tiene que manejar dos casos generales:

  1. cuando el servidor MongoDB está actualizado y se rompe la continuidad con el cliente, el cliente tendrá que
    1. sondeo de los datos (temporizador?) o
    2. mantienen un WebSocket abierta para que las notificaciones de flujo libre sobre el tubo
  2. cuando el usuario necesita para empujar cambiado datos de copia de seguridad de la tubería
    1. puede volver a conectar de forma asíncrona, comprobar si hay cambios de estado, (la resolución de conflictos de acuerdo con sus reglas de negocio)
    2. tienen una interfaz del lado del servidor (luz) para el manejo de conflictos (dependiendo de la complejidad de su aplicación , comparando las marcas de tiempo de los cambios de estado en MongoDB a actualizaciones IndexedDB debería ser suficiente)
+0

¿Sabe algo que ya podría haberse impuesto en este campo? Nuestro uso es un poco más simple en el sentido de que no se realizan cambios alguna vez localmente. El usuario solo puede realizar solicitudes de cambio enviadas al servidor y posiblemente aceptadas y/o rechazadas. Si son aceptados, deben ser devueltos al cliente. Por lo tanto, en este escenario, nunca podremos tener cambios locales y remotos en el mismo objeto. –

+0

puede haber algo en el ámbito de backbone.js, pero eso es una vit fuera de mi alcance. – patrickgamer

Cuestiones relacionadas