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.
Related
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
Done as follows but no column is added.
Migrate database
python manage.py db migrate
Edit migrations/versions/{version}_.py
def upgrade():
from alembic import op
op.add_column('table_name', Column('column_name', INTEGER) )
Update schema
python manage.py db upgrade
The reason is that alembic stores version in table called alembic_version, and once {version} is in alembic_version, then nothing happens.
The solution is to create a new migration script and do migrate again.
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
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.