Синхронизация базы данных django для автономного использования

У меня есть один мастер django, где хранятся данные (база данных mysql).

В сети: я бы хотел, чтобы у многих пользователей была синхронизирована копия из этой базы данных (только дельта должна быть скопирована) на их ноутбуках (sqlLite DB)

Offline (пользователи не имеют доступа к главному серверу): пользователи могут просматривать и обновлять свою локальную базу данных.

Back to Online: то, что было изменено на ноутбуках пользователей, синхронизируется с сервером master django.

Я думаю, поскольку у меня есть 2 типа базы данных, мне нужно синхронизировать на уровне объекта django. Существует ли приложение django? Если нет, как вы прокомментируете такую функцию?

Ответ 1

Оказывается, что я запускаю такую систему в Django.

Это не полный ответ, просто ответ, который в настоящее время решает (в основном) проблему.

Использование UUID для первичных ключей. Это значительно уменьшает вероятность столкновения первичных ключей для разных объектов.
Использовать среду сериализации Django для обмена данными. На центральном сайте администратора есть возможность загрузить выбранные объекты в списке изменений в совместимый с Django сериализованный файл. Затем пользователь может выйти в автономный режим и запустить локальный сайт администратора, а там загрузить серийный файл. При завершении автономной версии используется тот же самый процесс, в "автономном" админ-сайте объекты сериализуются в файл и загружаются на центральный сайт администратора.
Структуры сериализации очень полезны, поскольку вы можете получить фактический (и несохраненный) объект, затем решить сохранить его или нет и изменить некоторые поля перед сохранением.

Мы столкнулись с очень маленькими проблемами в этой простой системе, также помогли, поскольку контент правильно классифицирован, и редакторы только создают/редактируют неперекрываемый набор категорий.

Я поговорил с этим с некоторыми людьми и предложил мне несколько решений:

Используйте поле метки времени: это поможет решить, какую версию сохранить, а другую - отказаться.
Используйте поля версии с номерами мэра и младших версий. Незначительное редактирование (например, исправления правописания) только обновляет номер младшей версии, а основные изменения обновляют номер версии мэра и устанавливают значение "минус" равным 0. Таким образом, при сравнении вы всегда знаете, какой из них получает более высокий приоритет. Однако для этого требуется образование и соглашения в рамках пользователей редактирования.
Обновления объектов. Отдельная модель, в которой хранятся обновления, поступающие из автономных редакций. Затем "главный" редактор объединяет их в фактический объект, помогал с некоторыми дополнительными представлениями администратора для просмотра различий (с использованием патча google-diff-match-patch и т.п.). Объект также можно пометить, чтобы разрешить прямые обновления, то есть не хранить обновления и применять их непосредственно по прибытии. Неудобство - главный редактор должен пересмотреть все обновления, и это зависит от того, насколько информация обновляется.

Надеюсь, это поможет в некотором роде. Если кто-то решит что-то сделать, я буду рад услышать от него.

Ответ 2

Я создал приложение Django, которое делает это. Когда экземпляры модели создаются на удаленной/переносной версии приложения, они помечены как грязные и получают временный идентификатор. Удаленное приложение регулярно проверяет подключение к главному серверу. Когда есть сетевое соединение, то есть приложение подключено к сети, оно получает постоянный идентификатор для каждого нового экземпляра грязной модели с главного сервера. Временные идентификаторы заменяются постоянными идентификаторами, а затем грязные экземпляры синхронизируются с мастером.

Я использовал инфраструктуру Django REST для получения и обновления экземпляров грязной модели на главном сервере.

Обратите внимание, что для этого также требуется запуск локального веб-сервера на автономном компьютере. Я выбрал CherryPy для этого.

Ответ 3

Ну, я действительно не знаю, есть ли приложение django для этого, но я продолжу вот так:

создать метод для "offline_update": подключение к базе данных сервера, вы выбираете все объекты, чей идентификатор совпадает с идентификатором в локальной базе данных. вы обновляете локальную базу данных. затем вы выбираете остальные записи и добавляете их в локальную базу данных

создать метод для "online_update" той же самой процедуры, инвертированной.

PRO: легко реализуется (Objects.all() получает все, а затем вы манипулируете и обновляете или сохраняете напрямую)

CONS: условия гонки (что, если 2 пользователя обновляют одну и ту же запись (не обязательно в одно и то же время)? кто получил самую последнюю версию?)

вы в основном создаете своего рода "mysql-svn", чтобы обновлять 2 базы данных.

Я голосую +1 на ваш вопрос, потому что это действительно интересно. Я всегда работал, сбрасывая базу данных (через mysql), а затем загружая ее в локальную базу данных. без использования django.