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

Question

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

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

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

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

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

Answer 1

Ну, я на самом деле не знаю, если есть Джанго приложение, чтобы сделать это, но я приступаю так:

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

создать метод для «онлайн-обновления» той же рутинной, инвертированной.

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

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

вы в основном создаете своего рода «mysql-svn», чтобы обновить 2 базы данных.

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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