Миграции и два приложения совместно используют части базы данных на разных машинах - PullRequest
Новая
       9

Миграции и два приложения совместно используют части базы данных на разных машинах

0 голосов
/ 19 сентября 2018

Лучше описание - перефразирую проблему в новом разделе.

Вопрос : как организовать ./manage migrate на клиенте в следующей настройке:

  • Мне нужно создать веб-сайт django на клиентской машине, чтобы локальный пользователь мог войти туда и сделать что-то локально.
  • Существует также сервер с огромным приложением django, у которого есть пользователи.что-то делать на сервере.
  • И на клиентском компьютере есть приложение «просто python», которое получает данные, переданные с сервера, хранится локально и работает с локальной копией с помощью прямых запросов SQL (множество серверных таблиц-соединений).не используются), изменяя только две локальные таблицы, структура (но не данные) копируется с сервера для согласованности.

Серверное приложение django и клиентские приложения "just python" уже имеютустановленный протокол для подключения и передачи данных, чисто с сервера на клиент.Не все таблицы передаются (поскольку не все нужны), иногда на клиенте применяется только структура таблицы, иногда также данные.

Таблицы передаются так же, как содержимое "обычных таблиц Mysql" через некоторый XML / ssh / что угодно, теряя свои соединения django, в основном без аутентификации. * / Admin. * / Session. * / Content. * Tablesпередаются (как не относящиеся к делу), в то время как многие модели django имеют внешний ключ "updated_by_user" для (непереданной) таблицы пользователей.Это не имеет значения для клиента.

Нет, мне нужно создать локальную сеть django на клиенте, с

  • собственным набором пользователей, некоторые профили (подключено OnToOneдля локальных пользователей)
  • свои собственные локальные таблицы, которые доступны для чтения / записи для локального использования, но не конфликтуют с таблицами из общих таблиц сервера
  • (скопированы с сервера, только для чтения)на клиенте, иногда перезаписывается протоколом совместного использования)

Я пишу часть django на стороне клиента с нуля, у меня есть доступ к источнику серверной части (поэтому я могу скопировать models.pyнапример), но мне нужно добавить

  • локальные аутентификации
  • управлять содержимым таблиц "только локальные"
  • иметь возможность расширять их путем миграции, но делатьне изменять путем переноса существующих «из таблиц Mysql, скопированных с сервера»
  • использовать некоторые данные, отображаемые только из таких «таблиц копирования с сервера» (некоторые будут связаны внешним ключом из этих локальных таблиц.

Трудно обещать, что эти скопированные таблицы не сделают ничего дикого (просто увеличатся в длине, и в существующих записях будут максимально изменены некоторые логические столбцы, возможно, позже будут добавлены дополнительные поля, но ни одно из них не будет удалено или изменено - либо по структуреили по смыслу))

Вопрос - как мне создать свое «клиентское приложение django», чтобы его можно было обслуживать, сосуществовать (и работать с) серверными копиями таблиц.

Я могу создать свое приложение с объявлением некоторых моделей, перенести, скопировать «модели серверов», перенести с помощью --fake эту часть, а затем продолжить как обычно, но оно будет установлено на большем количестве клиентов, и структура общего доступаПозже таблицы могут добавить что-то, что мне нужно будет прочитать - так что еще одна --fake миграция

Есть ли способ сделать некоторые миграции по умолчанию "--fake", чтобы он вообще не мигрировал вообще, но не будут предлагаться как невыполненные (если эти модели будут меняться)?Или я просто должен назвать все такие миграции "0007_PLEASE_FAKE_ME" и делать это вручную каждый раз на каждом клиенте? Или ему нужен совершенно другой доступ?

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

Я даже могу отправить свои запросы на изменение модели сотрудникам "сервера", чтобы включить их в их models.py и передать их как "обновление только для структуры"

Я могу включить их models.pyМне также, если это изменится.

Тем не менее я не уверен, как мой профиль OneToOne для пользователя будет работать на сервере, где много уже установленных пользователей и ни одна модель профиля ...

версия Djago одинакова на сервере и клиенте (1.10), все таблицы MyISAM.

Спасибо за все предложения

Изменения (для @Thushar):

Клиенты обычно работают 24/7/365, таблицы переносятся в логическом порядке по зависимостям: сначала те, которые заканчиваются, затем те, которые ссылаются на них, ядро ​​ссылается на все остальные в последнюю очередь -таким образом, модель базы данных всегда согласована (просто может быть не завершена при передаче, все использованное уже имеет предварительные условия, уже переданные)

'Created_by' не используется (не обращается) на клиентах.Пока что клиенты запускают только некоторый код Python, который использует перечисление подмножества столбцов и таблиц.это работает около 5+ лет.

  1. Модификации сначала идут на сервер (который заполняет значения в таблицы), затем таблицы передаются клиентам, затем клиенты получают обновление ПО, которое использует новоефункции (поэтому он работает каждый раз по-старому или по-новому с совершенно новыми данными) Сервер использует django, клиенты используют простой SQL select name,filename, volume from themes where active=1

  2. изменения схемы базы данных сначала выполняются на сервере, затем передается клиенту, затем клиент sw обновляется для использования новых столбцов (например, SQL ... AND plaing_allowed=1. Изменения обратно совместимы, поэтому даже клиент с 10 версиями устаревшего ПО может работать с полностью актуальными данными, просто пропуская некоторые новые функции.

  3. API для переноса базы данных довольно стабилен (даже если он немного медленный), передает некоторую форму данных TXT / XML по SSH (много раз никакое другое соединение не доступно для клиента) - с таблицейСначала описания, затем каждая измененная строка в порядке - и порядок переводов структурирован так, что может быть прерван в любой момент безвлияет на способность клиента работать.ПО на клиенте обновляется после базы данных, поэтому есть (старый клиент, старые данные - работает) (старый клиент, новые данные - работает как предыдущая версия вместе) (новый клиент, новые данные - работает как новая версия)

старый клиент просто игнорирует (не знает) о новых таблицах / полях и пропускает некоторые новые функции (также отсутствует способ вызова таких функций), поэтому он работает, как будто никаких изменений вообще не было.

О новых записях (строках) - сначала передаются зависимости (поэтому нет возможности их использовать), затем больше основных таблиц (которые затем уверены, что все используемые ими отношения уже существуют) - зависимостиявляются древовидными, поэтому возможно (и сделано) упорядочить его таким образом, чтобы сначала были переданы листья, потом - узлы, потом корень - (поэтому, если передача прервана, возможно, что некоторые листья / поддеревья являются "заблудшими"/ недоступно, но все доступное имеет все зависимости), это уже работает 5+ лет и десятки или сотни версий.Клиент гораздо больше «устройство», чем «компьютер», даже если он работает с полной ОС на платформе ПК - планы составляются на сервере, клиенты просто выполняют заказы и при необходимости выполняют необходимые вычисления.

Снова старый способ (django с mysql на сервере, python с mysql на клиентах) работает надежно долгие годы.

Не каждый раз, когда соединение клиент-сервер возможно, тогда клиенты предполагают работать «локально» на старых данныхДо тех пор, пока соединение снова не станет доступным (иногда через часы, иногда через месяцы).

Но «это просто работает».

Моя задача - создать новое приложение django, которое должнобыть выпущенным на некоторых (возможно, на всех) клиентах, что добавляет некоторые «локальные функции» к существующей схеме, в основном

  • имеет несколько новых таблиц для размещения некоторых планов и данных в
  • имеет некоторый веб-интерфейс, чтобы пользователи могли регистрироваться через веб-браузер непосредственно на клиенте (который сам по себе является небольшим сервером с apache + django + mysql) и планировать там некоторые локальные события - эти события НЕ распространяются обратно на главный сервер и не изменяются "официальные таблицы ", просто читает, что доступно и делает" локальные заметки "
  • эти" локальные заметки ", а затем использует уже существующий API на клиенте, чтобы замечать его в более отдельных задачах, которые необходимо сделать" прямо сейчаси здесь "- такой API существует уже и используется локально некоторым устаревшим приложением (запущенным на пользовательских ПК / NB), которое должно быть заменено веб-интерфейсом на это новое приложение django на клиенте.
  • цель -чтобы иметь возможность расширять веб-интерфейс для использования некоторых специальных «локальных таблиц», а также читать их «официально распределенные» и расширять локальный API, чтобы предоставлять больше возможностей, локальный API для этого (на клиенте) просто считывает данные из таблиц и актовна них, ничего не изменяя в базе данных.(Новая версия локального API должна читать и для локальных таблиц для большей функциональности)

Моя проблема в том, как разработать клиентское приложение django с учетом некоторых обновлений схемы базы данных "изредка случается на фоне ".

Новая версия нового приложения django может действительно утверждать, что все новые «фоновые изменения в глобальных таблицах» уже действуют, когда оно выпущено и требуются только изменения локальных таблиц.

Уже существующая система (оптимизированная для различных критериев) намного больше, чем новая часть, поэтому переписать ее с нуля не вариант.Также есть некоторые «не обновляемые части», такие, что старый способ связи должен быть поддержан в любом случае в новой версии, так как от него зависит какой-то компьютер, полностью недоступный для меня.(Но протокол связи спроектирован так, чтобы его можно было расширить, поэтому нет большой проблемы, добавьте туда еще немного информации)

Лучшее описание

  • Главный компьютер M и идентичныйподчиненные компьютеры S (1..x)
  • Мастер M запускает Myslql + Django + Apache и имеет 1 API (MS)
  • Мастер имеет таблицы TA (1 ..), TB (1..), TC (1 ..)
    1. Схема таблицы передачи MS API (аналогично CREATE TABLE) для всех таблиц TA и TB (либо полных, либо измененных)
    2. MS затем передает изменения данных для таблиц TA
    3. Таблицы TC вообще не переносятся
  • Slave S теперь работает Mysql +Старая программа и имеет 2 APIS
    1. MS API (для мастера по сети)
    2. S-local (XML основан на старой локальной связи OldApp )
  • Мастер (не регулярно, но достаточно часто, например, 1-10 раз в день) связывается с каждым ведомым устройством и через MS вызывает обновления базы данных на нем
  • Slave не обновляет таблицы на Master (ну, есть некоторые отчеты о состоянии и тому подобное, но это не обязательно и не интересно)
  • Slave выполняет свою работу (в основном, проигрывая музыку, основываясь на некоторых подсказках изТаблицы TA) независимо (планирование перестановок и так далее самостоятельно)
  • когда замечено XML из OldApp через S-local API, Slave останавливает то, что делает и воспроизводит соответствующее сообщение, затем продолжает
  • S-local API управляется каким-то устаревшим приложением с закрытым исходным кодом OldApp , которое должно быть заменено на NewApp (см. Далее)
    • OldApp работает на компьютерах пользователей (полностью отличается от главного и подчиненного) под Windows и имеет жестко закодированные строки XML для отправки на ведомый S
  • много информации изMaster M не имеет значения для Slave S (в основном для всех авторизаций и пользователей, поскольку решения по Slave основаны на различных критериях, а таблицы TA де-факто доступны только для чтения.e)
  • все это работает много лет, и из-за большого количества изменений в версии слишком велико, чтобы переписать в нормальное время.

Новый подход заключается в создании и запуске на базе Slave S NewApp приложения django (+ Apache), чтобы предложить лучшую и новую функциональность, чем OldApp для веб-страниц (размещенных на Slave S).)

Для этого требуется:

  • авторизация (отличается от Master, но все таблицы Master auth. * Находятся в группе TC и вообще не переносятся, поэтому могут быть локальноиспользуется повторно на ведомом устройстве
    • отличается для каждого ведомого устройства, не сообщается мастеру
  • читает некоторые таблицы группы ТА (но только читает, выполняетне изменять содержимое)
  • свой собственный набор таблиц TD (1..x) для сохранения - конфигурации, звуки и отношения - локальные для конкретного подчиненного устройства
    • , отличающиеся длякаждый ведомый, не сообщаемый мастеру
  • использует S-local API (и расширяет его немного - не проблема)

Опрошенрешение:

  • Скопируйте модели таблиц TD на Master и дайте их перенестиd с таблицами TB в подчиненные устройства (только структура)
  • аналогично переносят таблицы авторизации * в Master (в случае группы TB, только структуры, но не данные) в подчиненные устройства
  • установка новой версии в NewApp следующим образом:
    1. обновить TD на Master для синхронизации с новой версией TD в NewApp и выполнить миграцию на Master
    2. сделать перевод на подчиненных (так что новая версия там принудительно)
    3. обновить NewApp на подчиненных и использовать только ./manage.py migrate --fake, чтобы остановить жалобы

Нет проблем с MS API и его переносами (он просто работает, а значения по умолчанию в базе данных применяются к новым полям существующих записей / строк), созданием представлений и шаблонов (AFAIK, если таблица длямодель содержит больше полей, чем модель, такие поля просто игнорируются)

Таким образом, Master не будет использовать таблицы / модели TD никоим образом (без интерфейса, без администратора, просто будучи там пустым), а ведомый будет обновляться извнесинхронно с Учителем.В обоих случаях Models.py будет одинаковым в части данных (возможно, в некоторых таблицах TA / TB отсутствует основная функция TD и методы отсутствия подчиненных)

Вопросы

  1. может ли это работать таким образом (фальшивые миграции)
  2. существуют ли какие-то "системные" таблицы, необходимые (и автоматически управляемые) django на Master, которые необходимо перенести (в конце концов, с данными) в подчиненные устройства (вероятно,что-то о том, что выполняется миграция, или о структуре таблиц, необходимых для удовлетворения требованиям models.py) 2.1.такие таблицы переносятся, нужны ли даже поддельные миграции на Slave?(ИМХО их бы не было, так как в этих таблицах упоминаются все миграции и подходят модели)

1 Ответ

0 голосов
/ 22 сентября 2018

Я надеюсь, что под клиентской машиной вы подразумеваете какой-то локальный сервер, работающий 24/7, а не ноутбук / рабочий стол какого-либо клиента.

  1. Пожалуйста, поймите, что любое решение, включающее копированиетаблиц базы данных могут быть хрупкими, особенно когда есть внешние ключи, такие как created_by, которые указывают на пользователя, и в вашей локальной настройке им, возможно, придется указывать на какого-то локального пользователя (или одного фиктивного пользователя).

  2. Более того, могут быть и другие изменения базы данных в серверном приложении, и если вы не измените соответствующие модели в своем клиентском приложении Django, вы не сможете использовать их на стороне клиента, и если выдобавляем столбцы с помощью какого-либо другого инструмента, они могут больше не использоваться из Django.Любая таблица, созданная с использованием моделей django и измененная иначе, поставит вас в адское множество проблем.

  3. Так что одно точно, вам нужно будет внести изменения в оба приложения по отдельностивсякий раз, когда вы хотите внести какие-либо изменения.В любом случае, даже если вам удастся вносить изменения схемы локально и поддерживать ее «обратно совместимой», как ваше клиентское приложение узнает, что делать с этими новыми таблицами и столбцами, если не изменен код?

  4. Так что лучше избегать копирования таблиц и пытаться использовать более стандартный способ, например, использовать API для соединения двух систем, чтобы иметь полный контроль над тем, как копируются данные.

  5. Вы можете представить выбранные таблицы в серверном приложении через API, а на стороне клиента вы можете использовать систему, подобную django-celery-beat, для запуска cron, который обращается к API и извлекает последние данные из серверного приложения в форме JSON.и сохраните его в нужном формате в локальной БД.

  6. Всякий раз, когда есть какое-либо изменение в серверном приложении, и вам нужно это изменение в локальном приложении.Вы добавляете эти данные в ответ соответствующего API.И внесите изменения в клиентское приложение для извлечения и сохранения / использования этих данных.

  7. Пример, если в удаленном приложении есть модель покупок:

    класс Покупка (модели.Модель): customer_id = models.models.DateTimeField (auto_now_add = True)

А вам просто нужно использовать, customer_id, item & price в локальном приложении, создать API http://server_app.com/purchase,, который отправляет вам ответ, подобный этому.[{"customer_id": 4, "item": "soap", "price": 20}, {"customer_id": 5, "item": "toothbrush", "price": 10}, ...].Этот ответ может использоваться клиентским приложением и может быть сохранен в локальной модели, которая может выглядеть следующим образом.Вы также можете заставить систему отправлять обратно файл CSV для загрузки вместо ответа JSON, если объем данных велик. 

class CustomerTrend(models.Model):
    customer_id = models.ForeignKey(CustomerTable, related_name='purchased_by')
    item = models.CharField(max_length=50)
    price = models.PositiveIntegerField()

API действует как контракт между серверными и клиентскими приложениями,и вы вносите изменения в обе стороны только тогда, когда на стороне клиента требуются какие-то новые функциональные возможности, либо в существующих API, либо путем создания новых.Даже если какая-то база данных изменяется на сервере, и клиент не беспокоится об этом, поскольку ваш API продолжает посылать один и тот же ответ, клиентскому приложению все равно.Просто сделайте задание сельдерея, чтобы запускать этот API так часто, как это необходимо, чтобы получить необходимые данные.И создавать новые модели всякий раз, когда необходимы только обновления схемы.В любом случае, автоматическая синхронизация схемы будет бесполезной, если код вашего клиентского приложения не будет изменен, чтобы знать, что делать с новой схемой.

Обновление

Хорошо, после вашего редактирования одинМы уверены, что, поскольку речь идет об огромной и унаследованной системе, реструктуризация не возможна.Как я понимаю, вы хотите подключить пользовательский интерфейс на основе Django на стороне клиента в существующей системе.Давайте посмотрим, какие еще есть варианты:

  1. Вы можете применить поддельные миграции или можете вообще не применять никаких миграций.Пусть текущая система реплицирует данные / схему в вашей локальной системе.
  2. Скопируйте необходимые модели в ваше клиентское приложение Django in code.
  3. Будьте осторожны с любыми новыми моделями или столбцами, которые вы добавляете с обеих сторон, они должны иметь разумное значение default value, и еслиможно разрешить Null(None).Это будет поддерживать обратную совместимость в обеих системах, и вы не столкнетесь с Integrity Errors в клиентском приложении, если вы работаете с only a few columns.Это напоминает мне о другой унаследованной системе, над которой я работал (написано на C & PHP около 15 лет назад. Я работал над ней, когда ей было уже 12 лет).Мы привыкли придерживаться схожей стратегии: база данных совместно используется несколькими системами, и все они используют разные версии клиентов, ожидая разных данных.Вы можете просто выполнить однократную репликацию таблиц аутентификации, если вы используете пользовательскую аутентификацию Django, а затем отключить репликацию этой таблицы (как я понимаю, вы все равно не переносите данные в этих таблицах).Если вы используете аутентификацию по умолчанию, просто перенесите их отдельно во время первого развертывания в локальной установке.
  4. Как я уже говорил ранее, запуск поддельных миграций - это нормально, или они вообще не запускаются.Это вызов, который вы можете сделать только в зависимости от конкретного случая использования, чтобы вы могли лучше понять.Но если вы не применяете (фальшивые) миграции локально, вы не сможете применить какую-либо миграцию в будущем (поскольку во внутренней таблице миграции django не будет никаких данных).Если вы видите возможность иметь клиентские таблицы в будущем, то сделайте поддельные миграции.
  5. Суть в том, чтобы 2 системы (DB-replicator & Django) вносили изменения в схему в одной клиентской базе данных,или это станет некрасивым.Поскольку репликация БД является обязательной, код приложения на стороне клиента должен обеспечивать возможность ее работы с реплицированной базой данных (с использованием столбцов с правильными значениями по умолчанию и обнуляемостью).Изменения кода, сделанные в моделях для серверных и клиентских приложений, должны быть одинаковыми.(Обзоры кода должны сосредоточиться на этом, так как в будущем это может стать вашей единственной точкой отказа).
...