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 :(
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.
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
I have a django app called Locations and in its models.py there are 2 models:
class City(models.Model):
...
class Country(models.Model):
...
I did python manage.py schemamigration Locations --initial and then python manage.py migrate Locations. Everything worked fine.
Then I added 2 fields to City and did python manage.py schemamigration Locations --auto and it said:
Deleted field cover_image on Locations.Country
Added field lng on Locations.City
Added field ltd on Locations.City
Created 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.py. You can now apply this migration with: ./manage.py migrate Locations
Then when I did python manage.py migrate Locations, I got:
Running migrations for Locations:
- Migrating forwards to 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.
> Locations:0001_initial
FATAL ERROR - The following SQL query failed: CREATE TABLE "Locations_country" ("id" serial NOT NULL PRIMARY KEY, "name" varchar(100) NOT NULL UNIQUE, "slug" varchar(50) NOT NULL, "image" varchar(100) NOT NULL, "flag" varchar(100) NOT NULL)
The error was: relation "Locations_country" already exists
Error in migration: Locations:0001_initial
DatabaseError: relation "Locations_country" already exists
I always keep getting this error. Am I doing something wrong?
Then I did python manage.py migrate Locations 0003 --fake and this was the output:
- Soft matched migration 0003 to 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.
Running migrations for Locations:
- Migrating forwards to 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.
> Locations:0001_initial
(faked)
> Locations:0002_auto__add_field_city_lng__add_field_city_ltd
(faked)
> Locations:0002_auto__add_location__add_field_country_cover_image
(faked)
> Locations:0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit
(faked)
Now when I do python manage.py migrate Locations it says:
Running migrations for Locations:
- Nothing to migrate.
- Loading initial data for Locations.
Installed 0 object(s) from 0 fixture(s)
And those 2 fields have not been added. Whats going on? Whats the correct way to add/delete fields?
I have read the basic South documentation, please point to me if I have missed out something.
Thanks.
Delete 0002 and 0003 migrations files. And then roll back to 0001 by doing:
python manage.py migrate Locations 0001 --fake --delete-ghost-migrations
After that run schemamigration and migrate normally.
(During discussion with OP it was first cleared that 0002 and 0003 was never reflected to database, so it is no harm to delete those migration files from disk)
I am trying to make an app using Django and am using South to handle migrations. After I define the app's models.py, I include south in the "INSTALLED_APPS" in settings.py. Then I sync my database. When I validate the database, I get 0 errors. Then I execute the following commands on the command prompt:
C:\Users\abagaria\Desktop\IntegrateID\website>python manage.py schemamigration w
ebsite.integrate --initial
Creating migrations directory at 'C:\Users\abagaria\Desktop\IntegrateID\website\
website\integrate\migrations'...
Creating __init__.py in 'C:\Users\abagaria\Desktop\IntegrateID\website\website\i
ntegrate\migrations'...
+ Added model integrate.Publisher
+ Added model integrate.Author
+ Added model integrate.Book
+ Added M2M table for authors on integrate.Book
Created 0001_initial.py. You can now apply this migration with: ./manage.py migr
ate integrate
C:\Users\abagaria\Desktop\IntegrateID\website>python manage.py migrate website.i
ntegrate
Running migrations for integrate:
- Migrating forwards to 0001_initial.
> integrate:0001_initial
FATAL ERROR - The following SQL query failed: CREATE TABLE "integrate_publisher"
("id" integer NOT NULL PRIMARY KEY, "name" varchar(30) NOT NULL, "address" varc
har(50) NOT NULL, "city" varchar(60) NOT NULL, "state_province" varchar(30) NOT
NULL, "country" varchar(50) NOT NULL, "website" varchar(200) NOT NULL)
The error was: table "integrate_publisher" already exists
! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
! schema-altering statements in transactions, we have had
! to leave it in an interim state between migrations.
! You *might* be able to recover with: = DROP TABLE "integrate_publisher"; []
= DROP TABLE "integrate_author"; []
= DROP TABLE "integrate_book"; []
= DROP TABLE "integrate_book_authors"; []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
! NOTE: The error which caused the migration to fail is further up.
Error in migration: integrate:0001_initial
DatabaseError: table "integrate_publisher" already exists
I know that a lot of people have faced similar problems while using south, but usually in their case, they make the mistake of executing the "--initial" command more than once-- thereby causing south to make more than one __initial file in the migrations directory. But in my case, South thinks that the table already exists even when I make the first migration!
I have also tried:
deleting the migrations directory
deleting ghost migrations
making a "fake" migration
and then running the actual migration
Can someone please tell me how I fix this problem and can start defining my models again?
If you already have tables in database, do not use --initial, instead you need convert_to_south command. Delete directory "migrations", all tables from database and run the following commands:
python manage.py syncdb
python manage.py convert_to_south appname
python manage.py syncdb --migrate
http://south.readthedocs.org/en/latest/convertinganapp.html
I have a blank MySQL database that I've just created. south is in my INSTALLED_APPS.
I run:
$ ./manage.py syncdb
...
Creating table some_app_table
You just installed Django's auth system, which means you don't have any superusers defined.
...
Superuser created successfully.
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
Synced:
> django.contrib.auth
> django.contrib.contenttypes
...
Not synced (use migrations):
- myapp
...
$ ./manage.py schemamigration myapp --initial
+ Added model myapp.Model
...
Created 0003_initial.py. You can now apply this migration with: ./manage.py migrate myapp
$ ./manage.py migrate myapp
Running migrations for myapp:
- Migrating forwards to 0003_initial.
> skan:0001_initial
> skan:0002_initial
FATAL ERROR - The following SQL query failed: CREATE TABLE `myapp_model` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `user_id` integer NULL, `name` varchar(200) NOT NULL);
The error was: (1050, "Table 'myapp_model' already exists")
What's going on? Why won't South initialise correctly?
You already have some migrations defined: initial is (as expected) only needed for the initial migration.
Your syncdb output says:
Not synced (use migrations):
- myapp
Which indicates that south is working as expected. But, then you do:
$ ./manage.py schemamigration myapp --initial
+ Added model myapp.Model
...
Created 0003_initial.py. You can now apply this migration with: ./manage.py migrate myapp
Notice the 0003-prefix: this (most likely) indicates that there are already migrations defined. This is confirmed by the output of your next command:
$ ./manage.py migrate myapp
Running migrations for myapp:
- Migrating forwards to 0003_initial.
> skan:0001_initial
> skan:0002_initial
<snip>
In other words, you already have a couple of initial migrations, of which at least one will create that table. Your #3 migration tries this again, but fails, because the table of course exists by now.
What you need to do is only use initial on the creation of your Django app. As soon as the migrations folder contains a file called 0001_initial.py, you don't need any initial migrations anymore. If you change your table from this point on, call it with auto, and then migrate:
./manage.py schemamigration myapp --auto
./manage.py migrate myapp