DEV Community

ADONIS SIMO
ADONIS SIMO

Posted on

Is it really important to save django's migrations in a version control system ?

Hi mates, i am working with my team ( we are 4 in total) on a django project and any developer could make a modification on a model and then generate his migrations but sometimes it is really difficult to deploy the app after merge (even for tests), some reasons are : XXX_migration_XXX has been applied before his dependency XXX_migration_XXX, this is because of inconsistency between the differents Databases and the different migrations.

So i started to think that to avoid this kind of situation we should stop versionning the migrations. What do you think ? Did you sometimes fall in this kind a mess with migrations, (spaghetti migrations ;-) )?

PS : Sorry about my english

Oldest comments (7)

Collapse
 
tux0r profile image
tux0r

A VCS is too much effort in 9 out of 10 real life cases IMO.

Collapse
 
jjjjcccjjf profile image
endan

Care to explain why?

Collapse
 
tux0r profile image
tux0r

Because it adds complexity and maintenance cost to your workflow.

Thread Thread
 
simo97 profile image
ADONIS SIMO

like in my case.

Collapse
 
rhymes profile image
rhymes

Your issue is communication, not source control :-) You should probably consider using another branching strategy and if a feature requires changing the DB you should communicate it to the others, especially because you're 4, not 45.

This is a good guide on how to manage conflicts: algotech.solutions/blog/python/dja...

You can merge migrations or just squash them to a single file.

You obviously need the migrations in the source control, otherwise you won't be able to reproduce the schema from start or to create the next migration building on the previous one.

Collapse
 
jjjjcccjjf profile image
endan

In the framework me and my team are using, we use 1 migration = 1 table strategy.

Tables

Every time we pull a modified migration, we just run a script to automatically re-import and repopulate the database. Hope this helps.

Collapse
 
glind profile image
Greg Lind

I have run into this problem in the past and one strategy we have used is reset the migrations after each release. It has helped us keep the migration folder small, and it's bit easier to see the conflicting changes. I do think during development cycles if you isolate your applications and models per developer you eliminate almost entirely the conflicts from migrations if combined with a reset after release.