2011-07-29 29 views
16

Tengo un servidor maestro django donde se almacenan los datos (base de datos mysql).sincronización de la base de datos django para un uso fuera de línea

línea: me gustaría a muchos usuarios a tener una copia de esta base de datos sincronizada (único delta del deben copiarse) 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 Online: lo que se ha modificado en las computadoras portátiles de los usuarios se sincroniza de nuevo con el servidor master 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? De no ser así, ¿cómo procedería a codificar tal característica?

Respuesta

0

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

crear un método para "offline_update": la conexión a la base de datos del servidor, selecciona todos los objetos cuya identificación coincide con la de la base de datos local. usted actualiza la base de datos local. luego selecciona el resto de las entradas y las agrega a la base de datos local

crea un método para "actualización_en línea" la misma rutina, invertida.

PRO: fácil de implementar (objects.All() le consigue todo, entonces manipular y actualizar, o guardar directamente)

CONS: condiciones de carrera (lo que si hay 2 usuarios actualizar la misma entrada (no necesariamente en al mismo tiempo) ¿quién tiene el más actualizado?

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

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

+0

Hay otro problema: creo que no es una buena idea trabajar con las claves primarias de los objetos: como muchos usuarios pueden actualizar la base de datos maestra mientras que otros usuarios actualizan su base de datos fuera de línea, uno puede tener un choque en las claves primarias para objetos que no son lo mismo – Eric

+0

sí, la mía era sólo un ejemplo, básicamente "condiciones de carrera" en todas sus formas es el problema ... –

3

Resulta que estoy ejecutando un sistema como este en Django.

Esta no es una respuesta completa, solo la respuesta que actualmente está resolviendo (principalmente) el problema.

  • Uso de UUID para teclas principales. Eso disminuye en gran medida la colisión de teclas 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 utiliza 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 si guardarlo o no, y modificar algunos campos antes del guardado.

Hemos tenido muy pocos problemas con este sistema simple, también nos ayudó porque 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 propuesto varias soluciones:

  • utilizar un campo de marca de tiempo: que ayudan a decidir qué versión para guardar y uno para desechar.
  • 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 importantes actualizan el número de la versión del alcalde y establece el menor en 0. De esta forma, 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 diferente, que almacena las actualizaciones provenientes de ediciones sin conexión. Luego, un editor jefe los fusiona en el objeto real, ayudado con algunas vistas administrativas 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 la cantidad de información que se actualice.

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

+0

Sí, estoy de acuerdo con el principio del UUID: esa es la única forma de obtener objetos con la misma identificación en muchas computadoras. Pero necesito algo más automatizado ... Tendré que pensar más sobre esto ... – Eric

+0

+1 para UUID, que son tipos db de primera clase, si está utilizando PostgreSQL como su RDBMS. Soy un fan. – fish2000

1

Creé una aplicación Django que hace esto. Cuando se crean instancias 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 comprueba 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 modelos sucios 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 por eso.

Cuestiones relacionadas