I currently have an issue when working with my friends on the same Django project. The situation is that every time when any of us made database changes and if other people did not migrate on time, they will get ProgrammingError: Column not exist error. That already happened a couple of times and we are still not able to figure a way to avoid this. Question:
- What's the best way to solve this issue when happened?
- What's the best process to void this issue?
CodePudding user response：
I don't think it's a good idea to share the same database of the project that you're working on but, One of the Solutions that I use is by using Django's load data command, specially when you make a lot of changes into Django models
first, I run the dumpdata command after I make my initial data by doing
python manage.py dumpdata <app-name>
it will export a JSON file that you can later on load it into the database
python manage.py loaddata <app-name>
NOTE: for some reason, if you load the data and get an encoding error make sure to open the file and save it in notepad and change the encoding of it to utf-8
CodePudding user response：
If you are working on a local database then just migrate. This is everyday work in django. At least in my experience.
For databases that are shared, this is a different thing. I probably would (a) if no devops are in place, migrate the database directly after I have changed the schema. Make sure that a specific branch (i.e. development) is always in sync with your database server. Or (b) with devops in place, let a branch only merge if the condition is met: the migration that is tied to the model changes in your commit will be successful. And then let the devops handle the migration automatically to keep the database in sync.
.
During active development you can not avoid this issue. You can do your best to inform your colleagues when you push code or merge a feature into development. I.e. by putting a warning in the commit message.
Anyway, everyone should be aware that the database schema might change when rebasing on current development or pulling. Generally your changelog should at least contain information on what fields were added/changed/removed.