With Django 1.11.22 I'm trying to run migrations
python manage.py migrate
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration base.0036_auto_20190227_1226 is applied before its dependency base.0027_auto_20170801_1228_squashed_0037_auto_20190222_1347 on database 'default'.
My first try to solve this was
sudo -u postgres psql -d albatros -c \
"DELETE FROM django_migrations WHERE name = '0036_auto_20190227_1226' AND app = 'base'"
In the hope of deleting the migration from the migration table would fix it. Unfortunately I'm now getting:
CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0037_auto_20190222_1347, 0036_auto_20190227_1226 in base).
To fix them run 'python manage.py makemigrations --merge'
When tryin makemigrations --merge it does not find any migrations to merge. This is what showmigrations looks like:
./manage.py showmigrations base
base
[X] 24_initial
[X] 24_to_26
[X] 26_to_27
[X] 0027_auto_20170801_1228
[X] 0028_resourcebase_is_approved
[X] 0029_auto_20171114_0341
[X] 0030_auto_20180309_0833
[X] 0031_auto_20180309_0837
[X] 0032_auto_20180329_1844
[X] 0033_auto_20180330_0951
[X] 0034_auto_20180606_1543
[X] 0035_resourcebase_dirty_state
[ ] 0036_auto_20190227_1226
[ ] 0036_auto_20190129_1433
[ ] 0037_auto_20190222_1347
Can one say how to correctly apply the migrations and solve the multiple leaf nodes error?
In this 2 migration files (0037_auto_20190222_1347, 0036_auto_20190227_1226) you have same dependencies, check them. They seems like a list with tuple in it
dependencies = [
('round', '0008_auto_20200116_0752'),
]
You need to manually write "0036_auto_20190227_1226" into 0037_auto_20190222_1347 file dependencies variable.
each django migration contains a dependency referring to the migration before it, as if it were a breadcrumb, this is controlled through the files that are in the migrations folder as well as through the database, in the django_migrations table. Each migration file has a line something like this:
dependencies = [
('round', '0008_auto_20200116_0752'),
]
where the second parameter of the tuple must be exactly the name that must be in the database in the django_migrations table. That way the tree cannot have loose nodes, make sure your database in the django_migrations table is consistent with the migration sequence of each file through the dependencies:
dependencies = [
('round', '0008_auto_20200116_0752'),
]
An alternative to resolve this would be to use django-migration-fixer
Fixing migrations on your dev branch can be done using
$ git checkout [dev-branch]
$ git merge [main/master]
Follow the installation instructions here
Run
$ python manage.py makemigrations --fix -b [main/master]
commit the changes and push to the remote branch
$ git add .
$ git commit -am ...
$ git push ...
You can merge your migration and do migrate
(venv)yourprj$python manage.py makemigrations --merge
(venv)yourprj$python manage.py migrate
Related
suppose that this is the migrations history to my project:
[X] 0001_initial
.
.
.
[X] 0010_auto_20211202_0923
[X] 0011_auto_20211202_1050
[X] 0012_auto_20211202_1240
[X] 0013_auto_20211202_1522
[X] 0014_auto_20211202_1534
[X] 0015_auto_20211202_1555
[X] 0016_auto_20211202_1567
.
.
.
[X] 0021_data_migration
I would like to create a new migration in the middle of the history, between 000_13 and 000_14.
You have to back migrate to 0013, create a new migration and then refactor all name and dependency and migrate again.
python manage.py migrate appname 0013_auto_20211202_1522
python manage.py makemigrations
python manage.py migrate
idk if that's possible.
You could just reverse your migrations and start again?
python manage.py migrate appname zero
python manage.py makemigrations
python manage.py migrate
Then you'd start from 0001 again.
There was a change in the DB and the Model was modified. After running Makemigrations, I ran migrate.
The DB has been changed normally, but the history is not added to the django_migrations Table.
Because of this problem, a warning to continue to migrate appears even after migrating. And when I try to migrate again, the history is not added to the django_migrations table, so I try to change the DB as before, and this is of course an error.
This is migrations file.
class Migration(migrations.Migration):
dependencies = [
('common_py', '0001_initial'),
]
operations = [
migrations.AddField(
model_name='customer_company',
name='del_date',
field=models.DateTimeField(default=None, null=True, verbose_name='삭제일'),
),
]
Run command "python manage.py migrate"
Result
(venv) PS D:\Projects\AFF\AFF> python manage.py migrate
Operations to perform:
Apply all migrations: auth, common_py, contenttypes, sessions
Running migrations:
Applying common_py.0002_customer_company_del_date... OK
Change Table Success
But didn't add history to "django_migrations" Table
Have you any idea? I Couldn't find any information about this. Thank you.
I turned off autocommit of mariadb. To use transaction in my Django program.
This is the reason of problem. I guess that the "python manage.py migration" command is not using transaction commit.
Solution.(Os windows)
open mariadb config file.
C:\Program Files\MariaDB 10.5\data\my.ini
Then add(or change) this line in
[mysqld]
autocommit=1
Restart pc or mariadb.
Complete.
Here is my current status:
mainapp
[X] 0001_initial
[X] 0002_authorprofile_uuid
[X] 0003_auto_20151107_1243
[X] 0004_article_approved
[X] 0005_auto_20151129_0950
[X] 0006_article_category
[X] 0007_auto_20160501_1601
I want to go back to 0005. However, when I run /manage.py migrate mainapp 0005_auto_20151129_0950 I get the error ValueError: The database backend does not accept 0 as a value for AutoField.
This is an error I've fixed in models.py, so I want to go back to 0005 and start fresh, and re-do the migrations.
class Article(models.Model):
category = models.ForeignKey(Category, default = 1) #trying to add this and set default value. It was first set to 0 but changed it to 1 after it failed
My suggestion is to open up your sql console and dump the django_migrations table.
DELETE FROM django_migrations WHERE app='mainapp'
Then make sure all your files in the migrations/ folder have been checked into version control and delete them! Then do
./manage.py makemigrations mainapp
./manage.py migrate mainapp --fake
If --fake doesn't work, it's time for desperate measure and --fake-initial but then it's very likely that when you deploy your app some where else you are going to have to go through this all process again :(
I'm trying to migrate django apps, and i have problem with one. When i run
python manage.py migrate --list |grep -v "*"
i get output
dbtemplates
( ) 0001_initial
( ) 0002_auto__del_unique_template_name
( ) 0003_initial
I jut downloaded dbtemplates package, and in downloaded folder migrations are 3 files:
__init__.py
0001_initial.py
0002_auto__del_unique_template_name.py
So in my django project 0003 shouldn't be here i think. Should i remove 0003, mark as fake? If i need to remove 0003 migration, where can i find this package?
python manage.py shell
[1]: import dbtemplates
[2]: dbtemplates
This show the path package
In Django-South:
I changed I've run the initial migration successfully for myapp but for some reason, after I've made a change to my model and go to
./manage.py schemamigration myapp --auto
./manage.py migrate myapp
And I get a lot of traceback which ends in:
(1050, "Table 'my_table' already exists")
After much googling, I found and tried this:
./manage.py migrate myapp --fake
And then I proceed to migrate it, to no avail; same error.
Any suggestions?
I just got this same error, and found this question by search.
My problem was that my second migration I'd created using the --initial flag, i.e.
$ ./manage.py startapp foo
$ ./manage.py schemamigration --initial foo
$ ./manage.py migrate foo
... make some changes to foo ...
$ ./manage.py schemamigration --initial foo
(oops!)
$ ./manage.py migrate foo
... and I get the error, and the migration fails because in the second migration, South is trying to create a table its already created.
Solution
In my migrations folder:
$ ls foo/migrations
0001_initial.py 0002_initial.py
remove that second migration and re-export the second migration with the correct --auto flag:
$ rm foo/migrations/0002_initial.py
$ ./manage.py schemamigration --auto foo
$ ./manage.py migrate foo
Success!
There may be other things that cause this error, but that was my bad!
Is it an existing app?
In that case you will need to convert it in addition to the fake bit.
There are good docs here on converting an existing app.
Although they are quite tricky to find if you don't know where they are already ( ;
For converting, after adding south to your installed apps:
./manage.py syncdb
./manage.py convert_to_south myapp
./manage.py migrate myapp 0001 --fake
this problem actually happens if one of the cases:
1) You made "schemamigration app_name --initial" after one is "--auto"
2) You interrupted the last migration you have made.
To resolve such problem you apply the following:
1) mark your last schema migration as fake.
python manage.py schemamigration app_name --fake
Note: Make sure that the schema of models is same as schema of tables in database.
2) apply the migration again by doing
python manage.py schemamigration app_Name --auto
python manage.py migrate app-Name
Note: sometimes you might add manually a specific field you already added using the following syntax.
python manage.py schemamigration app_name --add-field My_model.added_field
For more info. regarding south, you could check its documentation here.