template - sincronización de la base de datos django para un uso sin conexión

django tutorial

Question

Tengo un servidor maestro de Django donde se almacenan los datos (base de datos mysql).

En línea: me gustaría que muchos usuarios tengan una copia de esta base de datos sincronizada (solo se deben copiar los delta) en sus computadoras portátiles (sqlLite DB)

Sin conexión (los usuarios no tienen acceso al servidor maestro): los usuarios pueden ver y actualizar su base de datos local.

Volver a en línea: lo que se ha modificado en las computadoras portátiles de los usuarios se sincroniza nuevamente con el servidor maestro de django.

Creo que, como tengo 2 tipos de base de datos, necesito sincronizar a nivel de objeto django. ¿Hay una aplicación django haciendo eso? Si no es así, ¿cómo procederá a codificar tal característica?

Answer 1

Bueno, en realidad no sé si hay una aplicación django para hacer eso, pero procederé así:

cree un método para "offline_update": conexión a la base de datos del servidor, seleccione todos los objetos cuyo id coincida con el de la base de datos local. Actualizas la base de datos local. luego selecciona el resto de las entradas y las agrega a la base de datos local

crear un método para "online_update" la misma rutina, invertida.

PRO: fácil de implementar (Objects.all () te proporciona todo, luego manipulas y actualizas o guardas directamente)

CONTRAS: condiciones de carrera (¿qué sucede si 2 usuarios actualizan la misma entrada (no necesariamente en el mismo tiempo)? ¿Quién tiene la más actualizada?)

básicamente creas una especie de "mysql-svn" para mantener las 2 bases de datos actualizadas.

Estoy votando +1 a tu pregunta, porque es muy interesante. Siempre he trabajado descargando la base de datos (a través de mysql) y luego cargando en la base de datos local. sin usar django.

Answer 2

Construí una aplicación Django que hace esto. Cuando se crean instancias de modelo en la versión remota / portátil de la aplicación, se marcan como sucias y obtienen una identificación temporal. La aplicación remota verifica regularmente la conectividad con el servidor maestro. Cuando hay una conexión de red, es decir, la aplicación está en línea, obtiene una identificación permanente para cada nueva instancia de modelo sucio del servidor maestro. Los identificadores temporales se reemplazan con identificadores permanentes y luego las instancias sucias se sincronizan con el maestro.

Utilicé el marco REST de Django para recibir y actualizar las instancias de modelo sucias en el servidor maestro.

Tenga en cuenta que esto también requiere ejecutar un servidor web local en la computadora fuera de línea. Elegí CherryPy para eso.

Answer 3

Resulta que estoy ejecutando un sistema como este en Django.

Esta no es una respuesta completa, solo la respuesta que actualmente resuelve (en su mayoría) el problema.

• Uso de UUIDs para claves primarias. Eso disminuye en gran medida la colisión de claves primarias para diferentes objetos.
• Utilice el marco de serialización de Django para el intercambio de datos. El sitio de administración central tiene una opción para descargar los objetos seleccionados en la lista de cambios a un archivo serializado compatible con Django. Luego, el usuario puede desconectarse e iniciar un sitio de administración local, y allí, cargar el archivo serializado. Cuando finaliza la edición sin conexión, se usa el mismo proceso, en el sitio de administración "fuera de línea" los objetos se serializan en un archivo y se cargan en el sitio de administración central.
• Los marcos de serialización son muy útiles, ya que puede obtener un objeto real (y no guardado), luego decidir guardarlo o no y modificar algunos campos antes de guardar.

Nos hemos encontrado con muy pocos problemas con este simple sistema, y ​​también hemos ayudado ya que el contenido está categorizado correctamente y los editores solo crean / editan un conjunto de categorías no superpuestas.

He hablado con esto con algunas personas y me propuso varias soluciones:

• Use un campo de marca de tiempo: Eso ayuda a decidir qué versión guardar y una a descartar.
• Utilice una versión de campos, con números de versión mayor y menor. La edición menor (como las correcciones ortográficas) solo actualiza el número de versión menor, y los cambios mayores actualizan el número de versión mayor y establecen el menor en 0. De esa manera, al comparar, siempre sabrá cuál obtiene mayor prioridad. Sin embargo, esto requiere educación y convenciones dentro de los usuarios de edición.
• Actualizaciones de objetos. Un modelo separado, que almacena actualizaciones provenientes de ediciones fuera de línea. Luego, un editor "jefe" los fusiona con el objeto real, ayudado con algunas vistas de administrador adicionales para ver las diferencias (usando google-diff-match-patch y similares). Un objeto también se puede marcar para permitir actualizaciones directas, es decir, no almacenar actualizaciones y aplicarlas directamente a la llegada. El inconveniente es que el editor ''jefe'' tiene que revisar todas las actualizaciones, y eso depende de cuánta información se actualice.

Espero que esto ayude de alguna manera. Si alguien decide implementar algo de esto, me encantaría saber de él.