Develop Reference

How to deal with `Migration is applied before its dependency`

I have been assigned the task to work on project involving react UI and django backend. There are two versions of this app:
older version which runs on older versions of react and python (v2)
newer version which runs on newer versions of react and python (v3)
I have been tasked to move some functionality from older version to newer version and test it with postgres database dump from a live environment running older version. The challenge could be differences in the database schema of newer and older versions. (But, most possibly there wont be much differences if some minor ones.)
So I proceeded to take the database dump, attached it to the database running on my laptop and specified its name in my django's settings.ini. But when I started my django app, it gave me error
You have 7 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, lab, otherlabs. Run 'python manage.py migrate' to apply them.
When I ran python manage.py migrate, it gave me an error:
Migration abc.0001_initial is applied before its dependency auth.0011_xyz on database 'default'.
So, I deleted record corresponding to abc.0001_initial from django_migrations table and reran python manage.py migrate. Now I got same error for migration of another project def but with the same dependency auth.0011_xyz:
Migration def.0001_initial is applied before its dependency auth.0011_xyz on database 'default'.
Should I proceed with deleting record corresponding to def.0001_initial too? Am afraid that this will continue till I delete all such 0001_initial-suffixed records. There are 35 projects and hence 35 such 0001_initial-suffixed records.
Q1. Is it safe to delete them all and run the migrations? Is deleting all migrations and rerunning them really bad idea if they are schema-only migrations (we use fixtures for importing data)? Or is it simply impossible to do as most of those migrations will fail as tables corresponding to most models are already there in the database (or this wont give any error?), so the only solution remained is to delete migrations record one by one from db till I get no errors. But wont this still give error as I am only deleting migrations record and not actual tables created by migrations? Is there any other approach?
Q2. Are migrations completely safe to "re"-run? I mean if one fails because corresponding table / columns are already there or for some other reasons, will it leave database in consistent state or will it mess up the database?
Q3. Also will it continue to execute rest of the migrations after one fails? OR
Q4. Can / should I execute rest of the migrations if one fails? If yes, do I need to pass some arguments to python manage.py migrate or its default behavior?
Update
I tried removing all migrations from the django_migrations table. And then running python manage.py makemigrations followed by python manage.py migrate. But migration did not complete and terminated with error "relation already exist". So applied fake migration python manage.py migrate --fake. It succeeded (seems that it faked / skipped all migrations as all corresponding tables were present, so it did not create new columns in already existing tables). But then my REST API calls started failing with error in response saying: "column xyz does not exist".
Manually copying data seems impossible since there are 156 tables 🥲
Please let me know if there are any solution to this.

You need to delete the migration row from django_migrations for migration def.0001_initial, then apply migrate auth 0011_xyz to fix the dependency and then you should can to do migrate def 0001_initial --fake to fake the migration and add the row you deleted before to django_migrations.

Moving a django postgres database to a new server leads to InconsistentMigrationHistory

I have an database dump file of my PostgreSQL database that was created by pg_dump.
I transfer this file to a new server. I also transferred all the relevant models.py files to this never server. I used the following command to load in all the data on the new server.
gunzip -c dump_file | psql -p port db_name db_user
I configured Django to access this database and I can query the data using manage.py shell_plus. For eaxmple, I can run Images.objects.all().count()which returns the correct number, i.e. the same number of image objects as were present on the old server.
Considering this is a different server, it does not contain any of the original migration files.
I used ./manage.py makemigrations to create the migrations files. This appears to work properly and migration files are created for each of my installed_apps.
Next, I run ./manage.py migrate. This leads to the following error:
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration shapes.0001_initial is applied before its dependency bsdfs.0002_auto_20200527_1647 on database 'default'.
All the answer on SO say to simply uncomment shapes from the installed_apps list, but this does not work because this leads to the following error when I'm importing it in the models.py. The models are extrmely big, and uncommenting each instance where shapes is being used it not possible.
RuntimeError: Model class shapes.models.Material doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS
What can I do to migrate the database properly?

I suppose you didn't have any migrations for the old db.
I assume pg_dump contained all the table-linkage information.
In this case, after running makemigrations you could try and create a table called django_migrations and manually insert a row that tells django that the 'initial migration' already ran (since your db is in sync with your code).
And when you run migrate, it should say, there's nothing to migrate.
And if later you change your model, the new migrations should be compatible, because your db is in sync now with your code.
If your app is 'contenttypes' and the filename of the migration is '0001_initial.py', you just set some past date for the applied column.

Uninstalling django-tinymce. Import error when makemigrations

Thanks for taking the time to read this.
I was not happy with TinyMCE extension in django and decided to switch to django-summernote. I first ran
pip uninstall django-tinymce
Removed all mentions of tinymce in the actual project.
Followed the instruction to install django-summernote. Upon completion I decided to run
python manage.py makemigrations
python manage.py migrate
to apply new extension, but get an error:
File "/Users/rasulkireev/Sites/dj-pw/now/migrations/0006_auto_20190703_0134.py", line 4, in <module>
import tinymce.models
ModuleNotFoundError: No module named 'tinymce'
I'm not sure why would Django care about what I did previously since I am simply asking to replace the editor. I can't run python manage.py runserver either.
I can't do anything before fixing this. I beg you guys, please help.
Note: I would ideally want to keep the contents of my current database.
Thanks for taking the time to read this.

Once you have removed all the mentions of tinymce from the models, admins and other files, you need to migrate using a special "flag":
python manage.py makemigrations
python manage.py migrate --fake-initial
I am not to clear on the backend of this method, but it works. You can read more about it the official Django website:
https://docs.djangoproject.com/en/2.2/topics/migrations/
This will make a new initial migration for your app. Now, run python
manage.py migrate --fake-initial, and Django will detect that you have
an initial migration and that the tables it wants to create already
exist, and will mark the migration as already applied. (Without the
migrate --fake-initial flag, the command would error out because the
tables it wants to create already exist.)
Note that this only works given two things:
You have not changed your models since you made their tables. For
migrations to work, you must make the initial migration first and
then make changes, as Django compares changes against migration files, not the database.
You have not manually edited your database - Django won’t be able to detect that your database doesn’t match your models, you’ll just get errors when migrations try to modify those tables.

New Django app initial DB migrations of an existing database

I have an existing database filled with a bunch of data. I want to migrate to Django so I went ahead and created the necessary models with python manage.py inspectdb. I haven't changed anything besides removed the managed = False since I want Django to manage the tables (mistake perhaps for initial migration?).
So now that the models are ready, how can I generate the first migration file so that I can start changing the fields to generate additional migrations (renaming a field here and there). I understand python manage.py migrate will handle the creation of Django-specific models but does not actually create any migration files? Some sources indicate the first migration file should be run with --fake so it's not applied. Will the next migration files remember to run the first one as fake and only apply the next ones?

You want makemigrations to create the migrations. The migrate command applies migrations, it does not create them.
You can use the --fake-initial option so that Django does not try to create the tables that already exist. Note that --fake and --fake-initial are two different commands.
When you run migrate, the django_migrations table is updated to store the currently applied migrations. The migration files themselves are not changed. The --fake command updates the django_migrations table without running the migration. That means that if you use it incorrectly your database and django_migrations table can get out of sync, which can be difficult to fix.

django 1.7 how to migration with existed tables

I upgrade to django 1.7
and need to deal with migration
My database already exists tables
Here is my step :
1.I delete the migration in django app test
2.I remove south(from INSTALLED APPS ) in django settings.py
3.run python manage.py makemigrations test
Migrations for 'test':
0001_initial.py:
- Create model Person
- Create model Book
- Create model Artical
run python manage.py migrate test
Operations to perform:
Apply all migrations: test
Running migrations:
Applying test.0001_initial... FAKED
is it right???
How to do migration if I already have tables?
Please guide me Thank you

it is right if the tables that exist in your database have the same structure as your current models (i.e. you haven't modified your models.py file after you applied you last migrations with South). If that's the case, you can proceed without worries.
If the structure is different, you can try different approaches:
Create the needed migrations manually. You will have to write your own migration with the needed modifications. Here you can find some example code of a migrations file for altering or adding fields and here you have the complete reference of the methods you can call
Modify your database manually with phpmyadmin, raw sql or the method you prefer.
Do a python manage.py dumpdata app1 app2 app3 > data.json, remove the db, create it again and to a python manage.py loaddata data.json. This may raise some errors because the data you saved was with the old structure, you will have to deal with each error.
Or the least preferred, if the data you had is not needed, just remove the db and recreate it.

There is nothing wrong with the way you are doing it.
The reason the first migration is faked is because your tables are already created:
Run python manage.py migrate. Django will see that the tables for the
initial migrations already exist and mark them as applied without
running them.
From the documentation on upgrading from South.