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:
- cuando el servidor MongoDB está actualizado y se rompe la continuidad con el cliente, el cliente tendrá que
- sondeo de los datos (temporizador?) o
- mantienen un WebSocket abierta para que las notificaciones de flujo libre sobre el tubo
- cuando el usuario necesita para empujar cambiado datos de copia de seguridad de la tubería
- 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)
- 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)
Usted debe ver si ninguno de los códigos de meteoros es relevante. – ranman
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 –
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 –