When I run python manage.py migrate on my Django project, I get the following error:
Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/home/hari/project/env/local/lib/python2.7/site- packages/django/core/management/__init__.py", line 363, in execute_from_command_line
utility.execute()
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 355, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 86, in handle
executor.loader.check_consistent_history(connection)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/db/migrations/loader.py", line 298, in check_consistent_history
connection.alias,
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.
I have a user model like below:
class User(AbstractUser):
place = models.CharField(max_length=64, null=True, blank=True)
address = models.CharField(max_length=128, null=True, blank=True)
How can I solve this problem?
Since you are using a custom User model, you can do 4 steps:
Comment out django.contrib.admin in your INSTALLED_APPS settings
INSTALLED_APPS = [
...
#'django.contrib.admin',
...
]
Comment out admin path in urls.py
urlpatterns = [
...
#path('admin/', admin.site.urls)
...
]
Then run
python manage.py migrate
When done, uncomment all back
Lets start off by addressing the issue with most of the answers on this page:
You never have to drop your database if you are using Django's migration system correctly and you should never delete migrations once they are comitted
Now the best solution for you depends on a number of factors which include how experienced you are with Django, what level of understanding you have of the migration system, and how valuable the data in your database is.
In short there are two ways you can address any migration error.
Take the nuclear option. Warning: this is only an option if you are working alone. If other people depend on existing migrations you cannot just delete them.
Delete all of your migrations, and rebuild a fresh set with python3 -m manage makemigrations. This should remove any problems you had with dependencies or inconsistencies in your migrations.
Drop your entire database. This will remove any problems you had with inconsistencies you had between your actual database schema and the schema you should have based on your migration history, and will remove any problems you had with inconsistencies between your migration history and your previous migration files [this is what the InconsistentMigrationHistory is complaining about].
Recreate your database schema with python3 -m manage migrate
Determine the cause of the error and resolve it, because (speaking from experience) the cause is almost certainly something silly you did. (Generally as a result of not understanding how to use the migration system correctly). Based on the error's I've caused there are three categories.
Inconsistencies with migration files. This is a pretty common one when multiple people are working on a project. Hopefully your changes do not conflict and makemigrations --merge can solve this one, otherwise someone is going to have to roll back their migrations to the branching point in order to resolve this.
Inconsistencies between your schema and your migration history. To manage this someone will have either edited the database schema manually, or deleted migrations. If they deleted a migration, then revert their changes and yell at them; you should never delete migrations if others depend on them. If they edited the database schema manually, revert their changes and then yell at them; Django is managing the database schema, no one else.
Inconsistencies between your migration history and your migrations files. [This is the InconsistentMigrationHistory issue the asker suffers from, and the one I suffered from when I arrived at this page]. To manage this someone has either manually messed with the django_migrations table or deleted a migration after it was applied. To resolve this you are going to have to work out how the inconsistency came about and manually resolve it. If your database schema is correct, and it is just your migration history that is wrong you can manually edit the django_migrations table to resolve this. If your database schema is wrong then you will also have to manually edit that to bring it in line with what it should be.
Based on your description of the problem and the answer you selected I'm going to assume you are working alone, are new to Django, and don't care about your data. So the nuclear option may be right for you.
If you are not in this situation and the above text looks like gibberish, then I suggest asking the Django User's Mailing List for help. There are very helpful people there who can help walk you through resolving the specific mess you are in.
Have faith, you can resolve this error without going nuclear!
Your django_migrations table in your database is the cause of inconsistency and deleting all the migrations just from local path won't work.
You have to truncate the django_migrations table from your database and then try applying the migrations again. It should work but if it does not then run makemigrations again and then migrate.
Note: don't forget to take a backup of your data.
This happened to me in a new project after I added a custom User model, per the recommendation in the django docs.
If you’re starting a new project, it’s highly recommended to set up a custom user model, even if the default User model is sufficient for you.
Here is what I did to solve the problem.
Delete the database db.sqlite3.
Delete the app/migrations folder.
Per #jackson, temporarily comment out django.contrib.admin.
INSTALLED_APPS = [
...
#‘django.contrib.admin’,
...
]
Also comment out the admin site in urls.py:
urlpatterns = [
path('profile/', include('restapp.urls')),
#path('admin/', admin.site.urls),
]
If you don't comment out the path('admin/'), you will get error "LookupError: No installed app with label 'admin'" when you run
python manage.py migrate
After the migrations finish, uncomment both of the above.
Here how to solve this properly.
Follow these steps in your migrations folder inside the project:
Delete the _pycache_ and the 0001_initial files.
Delete the db.sqlite3 from the root directory (be careful all your data will go away).
on the terminal run: python manage.py makemigrations
python manage.py migrate
Voila.
Problem
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.
So we can migrate database without admin(admin.0001_initial) firstly.
After its dependency migrated, execute commands to migrate admin.0001_initial.
Solution
remove 'django.contrib.admin' from INSTALLED_APPS in settings.py.
execute commands:
Python manage.py makemigrations appname
Python manage.py migrate appname
add 'django.contrib.admin' to INSTALLED_APPS in settings.py file.
execute commands again:
Python manage.py makemigrations appname
Python manage.py migrate appname
Before performing any other steps, back up your database. Then back it up again.
Remove any custom user model code out of the way, disable your custom model and app in settings, then:
python manage.py dumpdata auth --natural-primary --natural-foreign > auth.json
python manage.py migrate auth zero # This will also revert out the admin migrations
Then add in your custom model, set it in settings, and re-enable the app. Make sure you have no migrations on this app yet.
Then:
python manage.py makemigrations <your-app>
python manage.py migrate
python manage.py loaddata auth.json # Assumes your user-model isn't TOO dissimilar to the standard one.
Done!
Solved by commenting app admin before migration in settings.py
django.contrib.admin
and in urls.py,
('admin/', admin.site.urls)
uncomment after migrate
Just delete all the migrations folders, __pycache__, .pyc files:
find . | grep -E "(__pycache__|\.pyc|\.pyo$|migrations)" | xargs rm -rf
then, run:
python manage.py makemigrations
python manage.py migrate
When you are doing some changes to default user model or you are making a custom user model by abstractuser then lot of times you will face that error
1: Remember when we create a superuser then for logging in we need username and password but if you converted USERNAME_FIELD = 'email' then now you can't login with username and password because your username field is converted into email....
and if you try to make another superuser then it will not ask for username it will only ask for email and password and then after creating superuser by email and password only when you try to login in admin pannel then it will throw that error because there is not any username and username field is required
2: That's why after creating custom user model during migrate it will throw error so for
resolving it first add AUTH_USER_MODEL = 'appname.custommodelname' (appname is the app name where you definded your custom user model and custom model name is the name of the model which you gave to your custom user model) in your settings.py
3: Then delete the migrations folder of that app where you created that custom user model then delete the database db.sqlite3 of the project
4: Now run migrations python manage.py makemigrations appname(that app name where you defined your custom user model)
5: Then Migrate it by python manage.py migrate
6: That's it Now it is Done
In my case the problem was with pytest starting, where I just altered --reuse-db to --create-db, run pytest, and changed it back. This fixed my problem
You can delete directly db.sqlite3， then migrate a new database is automatically generated. It should fix it.
rm sqlite3.db
python manage.py makemigrations
python manage.py migrate
just delete the sqlite file or run flush the databse 'python manage.py flush'
and then run makemigrations and migrate commands respectively.
when you create a new Django project and run
python manage.py migrate
The Django will create 10 tables for you by default including one auth_user table and two start with auth_user.
when you want to create a custom user model inherit from AbstractUser, you will encounter this problem with error message as follow:
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.
I solve this problem by dropping my entire database, and create a new one. And this replaced the three tables I mentioned.
Your Error is essentially:
Migration "B" is applied before its dependency "A" on database 'default'.
Sanity Check: First, open your database and look at the records in the 'django_migrations' table. Records should be listed in Chronological order (ex: A,B,C,D...).
Make sure that the name of the "A" Migration listed in the error matches the name of the "A" migration listed in the database. (They can differ if you had previously, manually, edited or deleted or renamed migration files)
To Fix This, rename migration A. either in the database or rename the filename. BUT make sure the changes matches up with what other developers on your team have in their databases (or the changes matches what on your production database)
The order of INSTALLED_APPS seems important.
If you always put your recent works on top/beginning of the list they'll always be loaded properly in regard to django.contrib.admin. Moving my works to the beginning of the INSTALLED_APPS list fixed this problem for me.
The reason Kun Shi's solution may have worked maybe it ran the migrations in a different order.
There is another reason besides user error that can lead to this sort of problem: a known issue with Django when it comes to squashed migrations.
We have a series of migrations that work perfectly fine in Python 2.7 + Django 1.11. Running makemigrations or migrate always works as it should, etc., even (for the purpose of testing) when the database is freshly re-created.
However, as we move a project to Python 3.6 (currently using the same Django 1.11) I've been stuck trying to figure out why the same migrations apply just fine only the first time they are run. After that, any attempt to run makemigrations or even just migrate results in the error:
django.db.migrations.exceptions.InconsistentMigrationHistory
wherein migration foo.0040-thing is applied before its dependency foo.0038-something-squashed-0039-somethingelse (we only happen to have that one squashed migration... the rest are much more straightforward).
What's bugged me for a while is why this only happens on Python 3. If the DB is truly inconsistent this should be happening all the time. That the migrations appear to work perfectly fine the first time they are applied was equally confounding.
After much searching (including the present Q&A thread), I stumbled upon the aforementioned Django bug report. Our squash migration did indeed use the b prefix in the replaces line (e.g., replaces = [(b'', 'foo.0038-defunct'),.......]
Once I removed the b prefixes from the replaces line it all worked normally.
If you are working on an empty database a quick fix could be running the migrations for the account app, before any other app migrations.
$ ./manage.py migrate account
And then:
$ ./manage.py migrate
How to fix (Without delete migration folder or entire database)
Backup your database
Comment out your app in INSTALLED_APPS and AUTH_USER_MODEL = 'account.User' in your settings.py
python manage.py admin zero
Undo step 2
python manage.py migrate
Why this problem occured?
django admin app depends on AUTH_USER_MODEL which is default auth model when you create your django project.
If you migrate project models before change the AUTH_USER_MODEL, django admin app apply migration as django auth model dependency. However, you change that dependency and want to migrate models again. So, the problem is occured here; admin models applied before its dependency, which is your User model now, applied. Thus, You should revert admin models migrations and then try it again.
First delete all the migrations and db.sqlite3 files and follow these steps:
$ ./manage.py makemigrations myapp
$ ./manage.py squashmigrations myapp 0001(may be differ)
Delete the old migration file and finally.
$ ./manage.py migrate
If that exception was reveal itself while you are trying to create your own User model instead of standard follow that instruction
I have found my problem resolve by follow that instruction step by step:
Create a custom user model identical to auth.User, call it User (so
many-to-many tables keep the same name) and set db_table='auth_user'
(so it uses the same table)
Throw away all your migrations
Recreate a fresh set of migrations
Sacrifice a chicken, perhaps two if you're anxious; also make a backup of your database
Truncate the django_migrations table
Fake-apply the new set of migrations
Unset db_table, make other changes to the custom model, generate migrations, apply them
It is highly recommended to do this on a database that enforces
foreign key constraints. Don't try this on SQLite on your laptop and
expect it to work on Postgres on the servers!
If you set AUTH_USER_MODEL in settings.py like this:
AUTH_USER_MODEL = 'custom_user_app_name.User'
you should comment this line before run makemigration and migrate commands. Then you can uncomment this line again.
when you create a new project and with no apps, you run the
python manage.py migrate
the Django will create 10 tables by default.
If you want create a customer user model which inherit from AbstractUser after that, you will encounter this problem as follow message:
django.db.migrations.exceptions.InconsistentMigrationHistory:
Migration admin.0001_initial is applied before its dependency
account.0001_initial on database 'default'.
finally,
I drop my entire databases and run
I encountered this when migrating from Wagtail 2.0 to 2.4, but have seen it a few other times when a third party app squashes a migration after your current version but before the version you’re migrating to.
The shockingly simple solution in this case at least is:
./manage.py migrate
./manage.py makemigrations
./manage.py migrate
i.e. run a single migrate before trying to makemigrations.
This Problem will come most of the time if you extend the User Model post initial migration. Because whenever you extend the Abstract user it will create basic fields which were present un the model like email, first_name, etc.
Even this is applicable to any abstract model in django.
So a very simple solution for this is either create a new database then apply migrations or delete [You all data will be deleted in this case.] the same database and reapply migrations.
I have to drop my database to and then run makemigrations and migrate again for this to be resolved on my part.
delete migrations folder and db.sqlite3 and type in the cmd
python manage.py makemigrations
django.db.migrations.exceptions.InconsistentMigrationHistory #On Creating Custom User Model
I had that same issue today, and none of the above solutions worked, then I thought to erase all the data from my local PostgreSQL database using this following command
-- Drop everything from the PostgreSQL database.
DO $$
DECLARE
q TEXT;
r RECORD;
BEGIN
-- triggers
FOR r IN (SELECT pns.nspname, pc.relname, pt.tgname
FROM pg_catalog.pg_trigger pt, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pt.tgrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pt.tgisinternal=false
) LOOP
EXECUTE format('DROP TRIGGER %I ON %I.%I;',
r.tgname, r.nspname, r.relname);
END LOOP;
-- constraints #1: foreign key
FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pcon.contype='f'
) LOOP
EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
r.nspname, r.relname, r.conname);
END LOOP;
-- constraints #2: the rest
FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pcon.contype<>'f'
) LOOP
EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
r.nspname, r.relname, r.conname);
END LOOP;
-- indicēs
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='i'
) LOOP
EXECUTE format('DROP INDEX %I.%I;',
r.nspname, r.relname);
END LOOP;
-- normal and materialised views
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind IN ('v', 'm')
) LOOP
EXECUTE format('DROP VIEW %I.%I;',
r.nspname, r.relname);
END LOOP;
-- tables
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='r'
) LOOP
EXECUTE format('DROP TABLE %I.%I;',
r.nspname, r.relname);
END LOOP;
-- sequences
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='S'
) LOOP
EXECUTE format('DROP SEQUENCE %I.%I;',
r.nspname, r.relname);
END LOOP;
-- extensions (only if necessary; keep them normally)
FOR r IN (SELECT pns.nspname, pe.extname
FROM pg_catalog.pg_extension pe, pg_catalog.pg_namespace pns
WHERE pns.oid=pe.extnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
) LOOP
EXECUTE format('DROP EXTENSION %I;', r.extname);
END LOOP;
-- aggregate functions first (because they depend on other functions)
FOR r IN (SELECT pns.nspname, pp.proname, pp.oid
FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns, pg_catalog.pg_aggregate pagg
WHERE pns.oid=pp.pronamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pagg.aggfnoid=pp.oid
) LOOP
EXECUTE format('DROP AGGREGATE %I.%I(%s);',
r.nspname, r.proname,
pg_get_function_identity_arguments(r.oid));
END LOOP;
-- routines (functions, aggregate functions, procedures, window functions)
IF EXISTS (SELECT * FROM pg_catalog.pg_attribute
WHERE attrelid='pg_catalog.pg_proc'::regclass
AND attname='prokind' -- PostgreSQL 11+
) THEN
q := 'CASE pp.prokind
WHEN ''p'' THEN ''PROCEDURE''
WHEN ''a'' THEN ''AGGREGATE''
ELSE ''FUNCTION''
END';
ELSIF EXISTS (SELECT * FROM pg_catalog.pg_attribute
WHERE attrelid='pg_catalog.pg_proc'::regclass
AND attname='proisagg' -- PostgreSQL ≤10
) THEN
q := 'CASE pp.proisagg
WHEN true THEN ''AGGREGATE''
ELSE ''FUNCTION''
END';
ELSE
q := '''FUNCTION''';
END IF;
FOR r IN EXECUTE 'SELECT pns.nspname, pp.proname, pp.oid, ' || q || ' AS pt
FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns
WHERE pns.oid=pp.pronamespace
AND pns.nspname NOT IN (''information_schema'', ''pg_catalog'', ''pg_toast'')
' LOOP
EXECUTE format('DROP %s %I.%I(%s);', r.pt,
r.nspname, r.proname,
pg_get_function_identity_arguments(r.oid));
END LOOP;
-- nōn-default schemata we own; assume to be run by a not-superuser
FOR r IN (SELECT pns.nspname
FROM pg_catalog.pg_namespace pns, pg_catalog.pg_roles pr
WHERE pr.oid=pns.nspowner
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast', 'public')
AND pr.rolname=current_user
) LOOP
EXECUTE format('DROP SCHEMA %I;', r.nspname);
END LOOP;
-- voilà
RAISE NOTICE 'Database cleared!';
END; $$;
After this you can run django command for migrations
python manage.py makemigrations
python manage.py migrate
And Absolutely that will work . Thank You.
Comment django.contrib.admin from installed apps and also comment path('admin/', admin.site.urls),then rerun makemigrations and then migrate. It will solve your issue. For more info go here
These steps can as well work
Drop your entire database
Make a new migration
These few steps can solve it for you, and I think its best when you have multiple contributors to the sam project.
yekabathula-macbookair2:roster yekabathula$ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: staticfiles, messages
Apply all migrations: admin, contenttypes, api, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying api.0001_initial... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying sessions.0001_initial... OK
yekabathula-macbookair2:roster yekabathula$ python manage.py syncdb
/Library/Python/2.7/site-packages/django/core/management/commands/syncdb.py:24: RemovedInDjango19Warning: The syncdb command will be removed in Django 1.9
warnings.warn("The syncdb command will be removed in Django 1.9", RemovedInDjango19Warning)
Operations to perform:
Synchronize unmigrated apps: staticfiles, messages
Apply all migrations: admin, contenttypes, api, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
No migrations to apply.
After doing python manage.py migrate, tables are not created in database from my models.py it is able to create other tables from django_session etc. Is there anything else that I need to follow here ?
I was facing a similar problem in Django 1.10 and none of the above solutions worked for me.
What eventually worked was running this command:
python manage.py migrate --fake myappname zero
This reset all migrations (to the zeroth state)
This followed by :
python manage.py migrate myappname
created the tables for me.
If you do not want to roll back to the initial(zero) state but say to the migration number 0005(the last migration that worked), you can instead do this:
python manage.py migrate --fake myappname 0005
And then proceed with the actual migrate:
python manage.py migrate myappname
More details in the docs
In my case the __init__.py file was missing from the APP/migrations/ folder. If you don't have one, all it needs is an empty __init__.py file.
I ran into the same problem. After lots of digging, I found the solution.
I'm using django 1.11.
If you want to start-over,
1)delete all the files in your migrations folder except __init__.py
2)drop database
3)create database
4)python makemigrations
5)python migrate
if you have reset_db, instead of 2nd and 3rd steps you can use reset_db.
python manage.py reset_db
I am using MySQL and get into this issue after deleting 0001_initial.py migration file and all the custom tables evolved from DB to try to regenerate all they...
Solved this issue simply deleting these rows in django_migrations table...
After that, $ python manage.py migrate command regenerates all my custom tables again.
I had a similar problem and just figured it out.I have multiple databases. My local one (the one not being updated) is a MySQL database. The others are MS SQL Server and MySQL. I have routers to the other databases since I do not manage them and had (in Django 1.6) used the routers to indicate allow_sync() = False. With 1.7, I changed that to allow_migrate() = False. BUT I DID NOT ADD A ROUTER FOR MY LOCAL DATABASE. The default appears to be allow_migrate() = False if there is not one. As a result, the migrations just failed silently ( Reference: https://docs.djangoproject.com/en/1.7/topics/db/multi-db/). I added a router for my local DB, setting allow_migrate() to return True and now my migrations actually create my tables.
Change managed = True (if it is set to False) in models.py
class Meta:
managed = False
db_table = 'table_name'
To
class Meta:
managed = True
db_table = 'table_name'
I had a similar issue. I did everything stated above but nothing worked. Then I realized I had not added my model name in admin.py file in my app.
Along with everything stated above you have to also add your model name in admin.py file. You have to add it like this:
admin.site.register(model name)
This can be very frustrating, but here is method that worked for me.
First, if you've deleted the migration file go ahead and create it again
python manage.py makemigrations
Then compare the migration file with the SQL raw code and if it fit then apply migration
python manage.py sqlmigrate [app_name] 0001
python manage.py migrate
or you can simply pipe it from your command line or terminal
python manage.py sqlmigrate [app_name] 0001 | [psql] db_name username
BEGIN
CREATE TABLE
ALTER TABLE
COMMIT
NOTE: In my case I'm using postgresql. Though engine is similar to other database langauge, you might not get expected result.
Delete existing tables of the models in MySQL database.
Delete migration folder under app folder.
Delete all relative migration records in the table
"django_migrations" from MySQL.
Now you get clear model and database. Use
python manage.py makemigrations and python manage.py migrate
to create tables.
Hope to help you.
try this one,
run,
python manage.py makemigrations app_name
above command will make migrations, if successful then run second command or
check if you have typo in Installed_app and also check for AppConfig module
python manage.py migrate app_name
if above was successful, this will create the table in db
This solved the problem for me (I am using MySQL workbench by the way):
Run this sql: SET FOREIGN_KEY_CHECKS = 0;
Select all the tables in your django database (click on the first table, then press and hold shift, then click on the last table). Then right click and choose "Drop n tables" (where n is the number of tables you just selected)
then run python manage.py migrate
Finally restore foreign key check settings by running this sql: SET FOREIGN_KEY_CHECKS = 1;
Note: Before taking this drastic measure, I tried what Paulo Pessoa said in his comment, but still I got "No migrations to apply." messages. However, this solved the issue.
If you want to do it only for your application not from all the apps then Clear your application migrations records from 'django_migrations' table in your DB.
Python manage.py makemigrtions
python
Problem: : When you apply migrations in django for the first time, django creates table of that model in database and marks somewhere in its own file(class):
`initial = True`
When you then tries to alter the schema of that table it firstly checks
if initial = True
if an initial class attribute isn’t found, a migration will be considered “initial”
In case the initial = True we need to use
python manage.py migrate --fake-initial
For an initial migration Django checks that all of those tables already exist in the database and fake-applies the migration if so. Similarly, for an initial migration that adds one or more fields Django checks that all of the respective columns already exist in the database and fake-applies the migration if so.
Fake initial migration uses both CreateModel() and AddField() methods.
Solution:
>> python manage.py makemigrations <AppName>
>> python manage.py migrate --fake-initial
To avoid deleting critical databases, you may also consider silencing properties below the Class Meta: for example this model:
class Blog(models.Model):
category = models.CharField(max_length=100)
title = models.CharField(max_length=100)
date_added = models.DateTimeField()
merits = models.CharField(max_length=300, blank=True)
demerits = models.CharField(max_length=300, blank=True)
class Meta:
managed = True
db_table = 'weblog'
verbose_name_plural = "Blog"
#property
def content_min(self):
return truncatechars(self.content, 50)
You can then run makemigrations and migrate and your table will be created.
Check if you have added your created app to you installed apps under settings.py.
The list should seem like this:
INSTALLED_APPS = [
'django.contrib.admin','django.contrib.auth','django.contrib.contenttypes',
'django.contrib.sessions', 'django.contrib.messages','django.contrib.staticfiles',
'YourCreatedApp',
]
in my case just one app's tables of project doesn't recreate!
and this line of code recreate them and successfully run!
python manage.py migrate --run-syncdb
however i couldn't find main reason caused this kind of problem!
Delete database
delete migration folder
run migrate command
run makemigrations command
run migrate command
It will create all tables perfectly
Change from sqlite3 to mysql in settings.py
Make sure you have correct information regarding database name and username-password
Delete existing migration
Make migration
And then migrate
Make sure each app's migrations folder has a __init__.py file.
I had a similar issue, the connection with DB was set correctly as all the django admin tables were created on DB side. However, no models appeared in models.py
What worked for me is running in the console:
python manage.py inspectdb > models.py
which wrote everything into a new models.py file which then I replaced with the one I had in the app folder. Then I could alter the
managed = False
into
managed = True
here the link to the documentation: https://docs.djangoproject.com/en/3.1/howto/legacy-databases/
If you are a begginer like me make sure your classes extend models.Model. Then makemigrations and migrate.
class Cook(models.Model):
email = models.Field()
I solved a similar problem by doing this:
Delete all migration files and pycache so what retains is init.py
Comment all implementations of that table in models, serializers, admin, urls and views
Do python manage.py makemigrations
Do python manage.py migrate
Then, uncomment all implementations of that table in models, serializers, admin, urls and views
Then, do python manage.py makemigrations
Then, do python manage.py migrate
To elaborate on #Leman-Kirme 's answer.
I had a similar problem where the table for the model I added into models.py of one of my apps wouldn't get created when making and applying migrations. I tried different solutions but nothing seemed to work and I really didn't want to flush my databases. So what I did was:
Delete all the files in the migrations folder except for _init_.py
Delete all records in databases' django_migrations tables.
Manually make a migration file (copied from another project and changed the content so that migration would only make a model that I was having troubles with). Please, note, that it seems like it should be initial migration, i.e. 0001_initial.py
Run it.
Voila, here comes the table!
If you want / need, instead of deleting previous migrations' files and records in the databases, you could backup them and restore afterwards. You gonna need to edit name of your manually-created migration from 0001_initial to something like <number_of_existing_migrations>_fix
That worked for me (but I ignored step 6), I hope someone finds this useful as well!
Gist: => Delete entry from django_migrations and run the migrate command again.
This answer takes help from other answers, but still writing as there are different cases and my answer might help in your case.
After creating migration, I think by mistake I ran the command python manage.py migrate campaign --fake I am not sure if it did some wrong thing, so now running python manage.py migrate campaign was not creating tableSo what solved for me is--
in mysql shell run
select * from django_migrations; Note the id of last migration which is creating problem in my case it was 62delete from django_migrations where id = 62Now I ran the migration again, and it worked this time. with command python manage.py migrate campaign i.e. required table was created as a result of applying migration
The problem I discovered working with Postgres is that I had not set the schema. I the original question is one of those gotchas that may have a number of different answers, so if the other answers are not working for you just check this.
The "problem" is that Postgres has an additional "namespace" layer which means you can specify the database but there can still be a whole set of tables, still in the same database, but in another schema or namespace.
The tables in this schema may be unreachable because the user being used to connect does not have permissions, or in fact the schema has been specified, but the tables were created in a different schema, or even you haven't specified the schema this time and are looking in the public schema while the tables have been created in another schema.
So the solution is to set the schema correctly, to what you intend, in every location and place that you use it. This boils down to correct database settings in all the settings files you are using, and logging in to the right schema and user when you inspect the database manually.
For example:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'OPTIONS': {'options': f'-c search_path={"foobar"}'},
'NAME': 'foo',
'USER': 'bar',
'PASSWORD': 'barpass',
'HOST': 'baz.example.com',
'PORT': 5432,
},
}
The database name here is foo, the username is bar and the schema name is foobar. Adding this line to the OPTIONS parameter defaults the schema for all operations.
For other usage, within Postgres, you can display the current search_path, and alter it for the current session, or "permanently" for the database:
SHOW search_path;
SET search_path=foobar,public;
ALTER DATABASE foo SET search_path TO foobar;
If your problem was that Django was creating your tables, but just in the wrong schema or under different permissions, I hope this has resolved your issue.
This kind-of thing was happening to me when I would try to reset my DB. Nothing else would work to get django to recognize my tables except:
python manage.py migrate --run-syncdb
In my case those solutions didn't work to me
I have to:
Create a new app: py manage.py startapp new_app_name
Copy all the files in my new app
Run: py manage.py makemigrations
Run: py manage.py migrate
It works to me, I hope it could be useful for you too
Below commands worked for me
python manage.py makemigrations app_name
python manage.py migrate app_name
I had the same issue and lol I just forgot to change my engine to the needed one