The migrations documentation addresses this: Migrations are just Python files containing the old definitions of your models – thus, to write them, Django must take the current state of your models and serialize them out into a file. While Django can serialize most things, there are some things that we just can’t serialize out into … Read more
Simply creating a migrations directory at the root of your app (so users/migrations/ in your case) and adding an empty __init__.py file might resolve your issue. At least it did for me when I was getting the same error. But you’re better off running makemigrations for your app, as suggested by @zenofewords above. That will … Read more
I am not sure if it is OK to answer my own question, but i just figured out (i think). According to this bug report, i edited my code: from django.utils.deconstruct import deconstructible @deconstructible class PathAndRename(object): def __init__(self, sub_path): self.path = sub_path def __call__(self, instance, filename): ext = filename.split(‘.’)[-1] # set filename as random string … Read more
To answer your question, with the new migration introduced in Django 1.7, in order to add a new field to a model you can simply add that field to your model and initialize migrations with ./manage.py makemigrations and then run ./manage.py migrate and the new field will be added to your DB. To avoid dealing … Read more
You have to clear admin, auth, contenttypes, and sessions from the migration history and also drop the tables. First, remove the migration folders of your apps and then type the following: python manage.py migrate admin zero python manage.py migrate auth zero python manage.py migrate contenttypes zero python manage.py migrate sessions zero Afterwards, you can run … Read more
Django writes a record into the table django_migrations consisting of some information like the app the migration belongs to, the name of the migration, and the date it was applied.
python manage.py squashmigrations <appname> <squashfrom> <squashto> python manage.py help squashmigrations https://docs.djangoproject.com/en/dev/topics/migrations/#migration-squashing This will give you more granular control over which migrations to squash, and let you keep a cleaner commit history. Deleting + recreating all migrations may cause other issues such as circular dependencies depending on how models are constructed.
So the step-by-step plan I outlined in my question does work, but instead of deleting rows from the south_migrationhistory database table, I had to delete rows from the django_migrations database table. The command is: DELETE FROM django_migrations WHERE app=’my_app’ Once this is done, you will be able to re-run your migrations from scratch.
Because You have ForeignKey in operations, You must add a ook to dependencies: dependencies = [ (‘ook’, ‘__first__’), (‘eek’, ‘0002_auto_20151029_1040’), ] Django migrations have two “magic” values: __first__ – get module first migration __latest__ – get module latest migration
I got the same problem (column not exist) but when I try to run migrate not with makemigrations (it is the same issue I believe) Cause: I removed the migration files and replaced them with single pretending intial migration file 0001 before running the migration for the last change Solution: Drop tables involved in that … Read more