What is the best way to keep Django and SQLAlchemy models in sync?

R

Rrooom2014-09-22 09:50:56

Django

Rrooom, 2014-09-22 09:50:56

There is a site on django, and a service on tornado + sqlalchemy, which use several common tables. Since different people work on them, problems periodically arise - like crashes of one of the applications, when someone changed one of the models and the table, and not the other.
What's the best way to automate this? Now everything is done by hand. In principle - migrations, but it is not clear how to implement it. After all, standard migrations try to bring the structure of tables to the form of models, no matter how the changes are lost.

Reply

Answer the question

In order to leave comments, you need to log in

3 answer(s)

B

brutal_lobster, 2014-09-22
@brutal_lobster

A very inconvenient and slightly incomprehensible scheme :) Softins are somehow strongly connected, is it necessary to separate the processes of their development?
So that nothing falls off when changing - write tests! :)
And migrations will definitely help. Incremental development is everything :)
If changes are made equally and separately by both parties, centralize them (maybe even move migrations to a separate subrepository). Make sure that a merge pull request that changes models requires both parties to agree and pass some model compatibility tests.
Or do not single out migrations as a separate entity, but shift responsibility towards one project and tests, tests, tests ..

P

Pavel Solovyov, 2014-09-22
@pavel_salauyou

do a code review so that developers can imagine what is changing where

C

Concerto, 2016-09-17
@Concerto

Ideally, these should generally be separate services with separate databases. And the data between them must be shared through some kind of API (for example, HTTP).
- Someone who owns the shared data, for example, a service on Django (D)
- When the service on Tornado (T) needed data, it went through http in D, received the data and continued to process the request (while T went to D asynchronously)
- When service T needed to update data in D, it just pulled the API (sent POST / PUT) D.
- You share the code base. It becomes easier to test.
- You no longer need to synchronize migrations, now you just need a client library for another service.
- It is necessary to process services
- It will take more time to go to HTTP for data than to go to the database.
The division into services is now a trend and now there are many articles that describe the pros and cons in more detail.