Why there is no migrations detected but I just created new migrations? - django

This is my workflow, everything seems nice and tidy with makemigrations and migrate. However, I want to start over with my models, so I:
rm -rf all the migrations file in the django app directory;
drop all the related tables in the database;
makemigrations results in new migration files;
But when I want to migrate it into database, it is said No migrations to apply. I think the mechanism behind migrations is that models -> migrations -> database changes, if I drop the latter two it should go over again. Unfortunately it is not.
Django == 1.8.2
CLOSED There is a table called django-migrations tracking all the changes and delete related records and then I could make migrations. Thx to those who helped!

There's another table that keeps track of which migrations have been ran for each app, django_migrations. You'll have to reset that in order for django to know you have started over.
if you changed the database already then try running
python manage.py migrate <app> --fake zero

Related

Delete Heroku migrations

I read advices how to delete migrations but I don't understand what I'm doing and it's not working for me.
History. One day I had an issue when I added or renamed a model fields locally. So I was tired with that issue and I deleted all migrations and migrate again. And all was OK. But I remember that I will have a big problem when I will deploy on Heroku.
So the days are gone. And now it happened. :(((
I make migrations, migrate to a server database. Pushed my code, but.. it wrote me:
relation "accounts_goal" does not exist
LINE 1: SELECT COUNT(*) AS "__count" FROM "accounts_goal"
I understand it happened because locally I have 0001 and 0002 migrations, but on the server there are 0012 and etc. migrations. I think I need to delete all old migrations on the server. But I don't know how to do that. Help me please! Thank you)
At first, do not delete a table from the database before the migration. If you change your model, then manage.py migrate will do the thing. Django cannot detect the direct change of database; only knows the change of model script (makemigrations).
Sometimes migration doesn't work for no reasons. In that case, do the following things:
Undo the change of models.py (comment, delete).
manage.py makemigrations app-name.
manage.py migrate
Change the models.py again (as you wish).
Do the migration again.
Also you can try python manage.py migrate --fake.
If there is already a table present, Django will see that the initial migration has already been applied since the table is already present with old schema and therefore not taking the new table with different schema into consideration.
In that case, you need to drop tables in the database you can use python manage.py migrate app-name zero.

Used manage.py dbshell -> DROP TABLE to delete a database table, now I cannot recreate it

I am trying to use a custom Django management command to populate a db with scraped data. I messed this up on the first go so I deleted the table using python manage.py dbshell and then DROP TABLE player_player (Player is the name of the model). The table is now gone but when I re-run python manage.py makemigrations and python manage.py migrate it does not seem to recreate it. I tried deleting the migrations in the player application and ran python manage.py makemigrations again and it returned
Migrations for 'player':
player/migrations/0001_initial.py
- Create model Player
but when I run python manage.py migrate it says
Running migrations:
No migrations to apply
and does not recreate the Player db table.
Can anyone help with this? I was getting an error I couldn't solve so I figured I'd delete the table and try again since there was no data I cared about in there, but now think that was a poor decision.
This is because Django has a table named django_migrations that lists all the migrations that have been applied. Although you removed the table, Django still thinks it has applied the migration, because the name of the migration is listed in the table.
You can run the query:
DELETE FROM django_migrations WHERE name='0001_initial' AND app='player'
and then reapply the migration.
That being said, I would advise not to manually change the structure of the database. It might eventually result in putting the database in a state where fixing the database can be inconvenient.

relation "django_admin_log" already exists

when i try to run python manage.py migrate i run into following error
Upon running python manage.py run migrations it says no changes detected. and when i runserver it gives me warning that i have unapplied migrations as well.i have been searching internet for two hours but got not solution. Someone knowing the solution please share :)
The table in your database that stores migration data to keep track of what has been applied is out of date. Try running python manage.py migrate --fake
Try python manage.py makemigrations [app name] and if still, this does detect changes then delete the folder named migrations which is inside your application folder and then use this python manage.py makemigrations [app name]. Once migration happens successfully do the python manage.py migrate.
Don't Try This at Home
I faced this issue, i make two changes,
change AUTH_USER_MODEL, so i have one migraiton about it
second one add new field for my folder_model(migration name: folder_model 0021)
When my first migrate attempt(I already run makemigrations commands on local so i have migration files), it says;
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'
This error reiases because i change the AUTH_USER_MODEL in the middle of the project, normally you have to remove your database and fresh start from the beginnig(also truncate migrations etc.), according to Django doc -> https://code.djangoproject.com/ticket/25313
To fix this issue, you don't have to delete all migrations on db, just delete the migrations about admin(not from project just database)
After that just run
python manage.py migrate
It throws relation "django_admin_log" already exists. For this issue, run:
python manage.py migrate --fake
That's it, but not completely. Make fake migration act like you already make your all migrations successfully and save these on db. The issue came here that i have another migration about folder_model 0021 and with fake migration it doesn't applied to my database table but saved to db_migrations table.
So fix this issue, delete the folder_model 0021to database migration table (just 0021 not all folder_model migrations).
After delete just run python manage.py migrate
Everything is fine!

Django manage.py: Migration applied before its dependency

When running python manage.py migrate I encounter this error:
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
<appname>.0016_auto_<date2>_<time2> is applied before its dependency
<appname>.0001_squashed_0015_auto_<date1>_<time1>
running showmigrations returns:
<appname>
[X] 0001_squashed_0015_auto_<date1>_<time1> (15 squashed migrations)
[X] 0016_auto_<date2>_<time2>
[ ] 0017_<modelname>_squashed_0019_auto_<date3>_<time3> (3 squashed migrations)
I was trying out django-extensions yesterday, when it all got messed up after me running some direct SQL queries and I reset hard using git. I'm still learning about migrations, so I don't understand what is wrong, since it seems to me that both migrations already have been applied.
Thank you for your help!
This worked for me. I thank my coworker for sharing this knowledge after I searched online for many hours.
Start your db shell
python manage.py dbshell
Use the database you want. If you don't know, run .databases (SQLite) or SHOW databases
mysql>use <database_name>;
Retrieve all the migrations under your app
mysql> select * from django_migrations where app='<app>';
You will see the output with ids next to all migrations. Look at the migration you want to drop. Say the id is 361
mysql> delete from django_migrations where id=361;
You have squashed the migrations, so one of the dependencies that 0016_auto_<date2>_<time2> had is now part of the newly created squashed migrations. Meanwhile the 0016_auto_<date2>_<time2> has already been run and now you're trying to run the squashed migration.
I personally don't know if there's any way to fix this automatically. You will need to fix the issues yourself. If you have version control, revert these changes and try to rethink how you should squash the migration without affecting old ones.
I have solved this problem when i did (custom user model) by this steps:
delete this file :
migrations\0001_initial.py
delete this :
db.sqlite3
put this code in settings.py :
AUTH_USER_MODEL = 'users.CustomUser'
Then do (makemigrations) then (migrate )
run server .. the problem solved :)
i have used this link it is help me to solve the problem of dependency :
https://docs.djangoproject.com/en/3.1/topics/auth/customizing/
Due to limitations of Django’s dynamic dependency feature for swappable models, the model referenced by AUTH_USER_MODEL must be created in the first migration of its app (usually called 0001_initial); otherwise, you’ll have dependency issues.
In addition, you may run into a CircularDependencyError when running your migrations as Django won’t be able to automatically break the dependency loop due to the dynamic dependency. If you see this error, you should break the loop by moving the models depended on by your user model into a second migration. (You can try making two normal models that have a ForeignKey to each other and seeing how makemigrations resolves that circular dependency if you want to see how it’s usually done.)
run this python manage.py dbshell
INSERT INTO public.django_migrations(app, name, applied)
VALUES ('YOUR_APP_NAME, '0017_<modelname>_squashed_0019_auto_<date3>_<time3>', now());
and you should be fine. If Your migration was changing a lot to the database, then I am afraid it won't be that easy to fix it.
you need to fake migrations and migrate again
just make sure that you have a backup from your data because when you migrate again you need to delete apps table.
make sure that you look at show migrations and migrate un migrated apps by its sequence
Edit the dependencies of the conflicting migration, so that it no longer references the already applied migration.
Then run python manage.py migrate again and it should be fixed.
Warning: this only work suppossing that the state of the database matchs the state you get having applied the conflicting migration.
I had the same issue on 2020 with Django 3.0.6.
I tried all the relevant answers with no success. So I went in my database and deleted all the tables. You must export the relevant tables if you have done lot of work. I mainly delete django files in my database. And after, run:
python manage.py makemigrations <my-app>
And:
python manage.py migrate
Export your relevant tables if any.
First back up your database before resolving the conflicts, (Use "python manage.py dumpdata > db.json" for SQLite).
Execute python manage.py dbshell, to access the database.
Delete the migrations rows that are having conflicts from the django_migrations table.
Rename the tables conflicting in the database
Execute the makemigrations and migrate commands
After successful migrations, Drop the newly readded tables and finally restore the previously renamed tables to match the migrations need
I had the same problem, and here's how I solved it.
The following is my error message
File "/usr/local/lib/python3.11/site-packages/django/db/migrations/loader.py", line 327, in check_consistent_history
raise InconsistentMigrationHistory(
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration aaaa.0024_campaign_template is applied before its dependency bbbb.0005_templatemodel_from_template on database 'default'.
My solution
python manage.py migrate bbbb
python manage.py migrate
Because I changed the Django's app name in batches, the application order was not consistent when applied to the database. The bbbb that aaaa relies on was not created first, so I manually created the bbbb first
Migration file is not created for all app:
step 1:
create migration folder and add __init__.py file for all app
step 2:
delete db.sqlite3 database
step 3:
python manage.py migrate
python manage.py makemigrations
Delete all of your migrations folder
Delete the database(sqlite3)
Then run the makemigrations and migrate command
Delete the migration files.
Run:
python manage.py migrate
python manage.py makemigrations
python manage.py migrate
python manage.pyrunserver

Deleted migration files- how to makemigrations without losing data

I changed a field on a model class (which has no classes point to it, only one foreign key pointing out of it). Somehow, this stuffed up my migrations and it keeps saying "django.db.migrations.graph.NodeNotFoundError:" looking for migration files that do not exist.
I accidentally deleted several files in my 'migrations' folder.
My database contains a lot of data, and I do not want to break it.
Will I lose any data if I:
Remove the table that caused the problem in the first place (psql, \d, DROP TABLE tablename)
delete all my migration files
Re run the migration from the start?
./manage.py makemigrations
./manage.py migrate
Can anyone recommend another way of fixing this?
Here is the traceback:
http://dpaste.com/0Y1YDXS
Aren't you using git so that you can get your migration files back? If not, install and use it, starting now
I would suggest:
make a backup/dump of your database first, in case something goes wrong
Delete all migrations
Empty migration table in psql
call makemigrations
call migrate --fake-initial
Empty the django_migrations table:
delete from django_migrations;
Remove all the files in migrations folders in each and every app of your project.
Reset the migrations for the "built-in" apps:
python manage.py migrate --fake
Create initial migrations for each and every app:
python manage.py makemigrations your_app_name
Final step is to create fake initial migrations:
python manage.py migrate --fake-initial
See here https://micropyramid.com/blog/how-to-create-initial-django-migrations-for-existing-schema/