Как лучше синхронизировать модели Django и SQLAlchemy?

Question

[Rrooom]

Есть сайтик на джанго, и сервис на торнадо + sqlalchemy, которые используют несколько общих таблиц. Так как над ними работают разные люди периодически возникают проблемы - вроде крэшей одного из приложений, когда кто-нибудь поменял одну из моделей и таблицу, а другую нет.

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

Answer 1

[brutal_lobster]

Очень неудобная и немного не понятная схема :) Софтины как-то сильно связаны, нужно ли разделять процессы их разработки?
Чтобы ничего не отваливалось при изменении - пишите тесты! :)

А миграции однозначно помогут. Инкрементальная разработка - все дела :)

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

Answer 2

[Павел Соловьёв]

делайте code review, чтобы разработчики представляли, что где изменяется

Answer 3

[Concerto]

В идеале это вообще должны быть отдельные сервисы с отдельными базами. А данные между ними должны разделяться через какой-то API (например HTTP).

Примерно вот как будет выглядеть взаимодействие этих сервисов:
- Кто то владелец общих данных, например сервис на Django (D)
- Когда сервису на Tornado (T) понадобились данные, он сходил по http в D, получил данные и продолжил обрабатывать запрос (при этом T сходил к D асинхронно)
- Когда сервису T надо обновить данные в D он просто дернул за API (отправил POST/PUT) D.

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

Минусы:
- Необходимо перерабатывать сервисы
- На то, чтобы сходить по HTTP за данными понадобиться больше времени, чем на то, чтобы сходить в базу.

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