CODEWITHSUNDEEP
pythondjango
Gambit2007
Gambit2007

Reputation: 3948

Django - can't update model in database

I have a table in my database (postgresql) that is associated with a model called feedback in my Django app (which is also called feedback).

I deleted a couple of columns of the feedback model in the models.py file and then created a migration using:

python manage.py makemigrations feedback

And then tried to "merge" it with my database using:

python manage.py migrate feedback

But i got the error: django.db.utils.ProgrammingError: relation "feedback" already exists

Of course it exists, but i want to apply the changes i've made. In the migrations folder i have the following files:

__init__.py
0001_initial.py
0002_remove_feedback_created_on.py
0003_remove_feedback_is_read.py

The last one contains my most recent changes. What should i do?

Upvotes: 0

Views: 1599

Answers (2)

user8573812
user8573812

Reputation:

It could also help in the case of migrations.

python3 manage.py migrate --run-syncdb

Upvotes: 0

wanaryytel
wanaryytel

Reputation: 3482

Usually this relation x already exists problem appears when you've applied the change at some point in the database, but the Django migrations system hasn't got a clue about the fact that you already did that. How could it happen? For example if you add a ForeignKey field to your model, make a migration, migrate it, but then change your mind and delete the migration without migrating backwards before that. Nothing breaks in the project, but the relationship and the field in the database remain (you might run into trouble, if the field is non-nullable). Now if you change your mind again and decide that shiiit, I needed that field anyhows and add it again, make a new migration and try to migrate it, then you get the relation x already exists error.

Ok, what then? Usually the simplest way is to fake the failing migration, but BEWARE that if you have any other unapplied changes in the migrations, then those won't be applied to the database either. Before you start faking migrations, make sure that you understand what and why you are faking. Ideally you'd have only one AddField in the migration file that is soon to be faked, because otherwise all changes in the migration file will be faked (faking migrations means, that the changes are not applied to database, but Django will consider them done).

If you have two unapplied migrations, then you definitely shouldn't run migrate --fake without specifying the migration number, because then the latter unapplied migration will be unapplied as well. It SEEMS in your case, that running manage.py migrate 0002 --fake and manage.py migrate afterwards might fix everything, but without knowing everything about what you've done, it's impossible to say for certain.

If I picked up your project, here's what I would do:
1) Check if 0002 contains more than one change.
If yes, then copy everything except the failing field to 0003.
If no, then proceed to manage.py migrate 0002 --fake.
2) Run manage.py migrate again to migrate 0003.

Upvotes: 1

Related Questions