Is there any way to deal with the migrations ?
I have been working with the version 1.8 of django, where, after doing any change in the models.py, we need to run the following commands -
python manage.py makemigrations
python manage.py migrate
Many a times, this gives an error. And it so happens that I have to rebuild the project as there is no way out.
I also tried the following way-outs, but none of them worked.
deleted the migrations folder
undo the changes to model.py
deleted the files inside the migrations folder
tried with flushing, squashing the migratios
it every times shows the following error with a very long error log of some unknown files.
Post Edit : Here's the whole log
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/core/management/commands/migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/migrations/executor.py", line 147, in apply_migration
state = migration.apply(state, schema_editor)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/migrations/migration.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/migrations/operations/fields.py", line 62, in database_forwards
field,
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/backends/sqlite3/schema.py", line 179, in add_field
self._remake_table(model, create_fields=[field])
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/backends/sqlite3/schema.py", line 147, in _remake_table
self.quote_name(model._meta.db_table),
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/backends/base/schema.py", line 111, in execute
cursor.execute(sql, params)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/utils.py", line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/Library/Python/2.7/site-packages/Django-1.8.2-py2.7.egg/django/db/backends/sqlite3/base.py", line 318, in execute
return Database.Cursor.execute(self, query, params)
django.db.utils.IntegrityError: NOT NULL constraint failed: zapp_post__new.specs_order_post_id
Here is the link to my project, which currently is showing the error. You can try running the application
What should be done in this case ?
Downloaded your code, deleted db.sqlite3, ran syncdb, everything worked fine.
Since you didnt have any sensitive data in your db i think that works for you.
Here's a little extra info for future:
When modifying migrations/DB manually or when you run into a problem with migrations you should consider these things:
You should NOT delete migrations folder
Migrations folder should always contain __init__.py file
All applied migrations are stored in django_migrations table, so if you delete all migration files and remake migrations (i.e. creating a new 0001_initial.py), running migrate wont do anything, because django thinks it's already applied
Sometimes deleting specific rows in django_migrations table and also modifying your tables structure (according to deleted rows) solves the problem, but you should know what you're doing.
So, the easiest solution when you run into a problem with migrations is deleteing all files in migrations folder (except __init__.py), deleting all rows in django_migrations table where app=your_app_name, droping all tables of your app, then remaking migrations and applying them.
But if you have sensitive data and you can't delete db, it gets more complicated
Related
I am not sure whether I am doing something wrong or it is a problem with one of the pieces I am using for the project.
Basically, I added a field to a model and am trying to make a migration.
Here is the model. The field is the poster one.
class Video(models.Model):
title=models.CharField(max_length=500)
description=models.TextField(default="")
creation_date=models.DateTimeField(default=timezone.now)
videofile=models.FileField(upload_to='videos/', null=True, verbose_name="")
poster=models.ImageField(upload_to='video/thumbnails', null=True, verbose_name="")
tags = TaggableManager()
actions = ['delete']
def __str__(self):
return self.title + ": " + str(self.videofile)
...
That is the only thing that changed in the model. Let's make the migrations.
(app-web) selfishman#user-desktop:~/sites/app-web/app$ python manage.py makemigrations
Migrations for 'video_uploader':
video_uploader/migrations/0007_video_poster.py
- Add field poster to video
So far, so good. Let's try to apply the migration.
(app-web) user#user-desktop:~/sites/app-web/app$ python manage.py migrate video_uploader
Operations to perform:
Apply all migrations: video_uploader
Running migrations:
Applying video_uploader.0002_video_creation_date...Traceback (most recent call last):
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ut
ils.py", line 85, in _execute
return self.cursor.execute(sql, params)
psycopg2.errors.DuplicateColumn: column "creation_date" of relation "video_uploader_video" already exists
There rest of the backtrace:
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 20, in <module>
execute_from_command_line(sys.argv)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/core/managemen
t/__init__.py", line 381, in execute_from_command_line
utility.execute()
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/core/managemen
t/__init__.py", line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/core/managemen
t/base.py", line 316, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/core/managemen
t/base.py", line 353, in execute
output = self.handle(*args, **options)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/core/managemen
t/base.py", line 83, in wrapped
res = handle_func(*args, **kwargs)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/core/managemen
t/commands/migrate.py", line 203, in handle
fake_initial=fake_initial,
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/migrations/
executor.py", line 117, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/migrations/
executor.py", line 147, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/migrations/
executor.py", line 244, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/migrations/
migration.py", line 124, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/migrations/
operations/fields.py", line 84, in database_forwards
field,
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ba
se/schema.py", line 435, in add_field
self.execute(sql, params)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ba
se/schema.py", line 133, in execute
cursor.execute(sql, params)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ut
ils.py", line 100, in execute
return super().execute(sql, params)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ut
ils.py", line 68, in execute
return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ut
ils.py", line 77, in _execute_with_wrappers
return executor(sql, params, many, context)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ut
ils.py", line 85, in _execute
return self.cursor.execute(sql, params)
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/utils.py",
line 89, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "/home/user/miniconda3/envs/app-web/lib/python3.7/site-packages/django/db/backends/ut
ils.py", line 85, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: column "creation_date" of relation "video_uploader_video" already exists
This is the migration that was created:
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('video_uploader', '0006_video_description'),
]
operations = [
migrations.AddField(
model_name='video',
name='poster',
field=models.ImageField(null=True, upload_to='video/thumbnails', verbose_name=''),
),
]
Could someone tell me what is going on here? I am using Postgres 12. When I run tests, and an (SQLite) DB is created from scratch, there is no such error.
Any help is appreciated.
P.S. We have seen quite a few inconsistencies when it comes to Django migrations and Postgres/Psycopg2. Not sure if something is up with the config or versions/dependencies.
You created a new migration and it was named
0007_video_poster
However when you run the migrate it is running
0002_video_creation_date
And this is trying to create a new column named creation_date however that's already there.
You are getting inconsistent results because django thinks the previous migrations were not applied and therefore it is trying to apply them.
The easiest way would be to flush the database (make sure you first export any data you might need) using
python manage.py flush
This would reset the database and then you can run the migrations normally and it should work fine.
Otherwise if you want to execute the migration you just created i.e. 0007_video_poster
You can run this
python manage.py migrate video_uploader 0007_video_poster
I'm trying to run a Django 1.11 migration on a PostgreSQL 9.6.5 database, and I'm getting the odd error:
Applying myapp.0011_auto_20171130_1807...Traceback (most recent call last):
File "manage.py", line 9, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
utility.execute()
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 356, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 204, in handle
fake_initial=fake_initial,
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 115, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 145, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/migrations/migration.py", line 129, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/migrations/operations/models.py", line 536, in database_forwards
getattr(new_model._meta, self.option_name, set()),
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 349, in alter_unique_together
self._delete_composed_index(model, fields, {'unique': True}, self.sql_delete_unique)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 380, in _delete_composed_index
self.execute(self._delete_constraint_sql(sql, model, constraint_names[0]))
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 120, in execute
cursor.execute(sql, params)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: constraint "idx_32269_myapp_mymodel_title_333195ae82ac2107_uniq" of relation "myapp_mymodel" does not exist
The migration is changing a unique contract from including one column to two. Pretty simple. It needs to destroy the old index, "idx_32269_myapp_mymodel_title_333195ae82ac2107_uniq", before creating the new one. However, it fails because it doesn't think the old one exists.
So I connected to the database with pgAdminIII and inspected the table, and contrary to the error message, the table does have an index called idx_32269_myapp_mymodel_title_333195ae82ac2107_uniq.
I thought maybe Django is using slightly different connection parameters, and is connecting to a different database? Let's try inspecting it from inside a Django dbshell. So I started manage.py dbshell and ran:
SELECT *
FROM pg_stat_all_indexes
WHERE indexrelname='idx_32269_myapp_mymodel_title_333195ae82ac2107_uniq';
and it returned one row.
Why is Django unable to see this index during a migration, even though the index definitely exists in the database?
The problem turned out to be that I converted the database to PostgreSQL from MySQL using the tool pgloader, and this tool converts constraints by creating them as indexes in PostgreSQL, whereas the Django PG backend creates them as constraints. So when the migration runs, it only looks for constraints and doesn't find any.
I fixed this by dropping the index and re-creating it as a true constraint with:
DROP INDEX idx_32269_myapp_mymodel_title_333195ae82ac2107_uniq;
ALTER TABLE public.myapp_mymodel ADD CONSTRAINT idx_32269_myapp_mymodel_title_333195ae82ac2107_uniq UNIQUE(title);
After that, the Django migration ran correctly.
I am trying to migrate my database:
E:\PhytonProgects\natarelke>python manage.py migrate
System check identified some issues:
WARNINGS:
?: (mysql.W002) MySQL Strict Mode is not set for database connection 'default'
HINT: MySQL's Strict Mode fixes many data integrity problems in MySQL, such as data truncation upon insertion, by escalating warnings into errors. It is strongly recommended
you activate it. See:
https://docs.djangoproject.com/en/1.10/ref/databases/#mysql-sql-mode
Operations to perform:
Apply all migrations: admin, auth, catalog, contenttypes, main, ordering, registration, sessions, users
Running migrations:
Rendering model states... DONE
Applying catalog.0002_auto_20170219_2146...Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "C:\Python27\lib\site-packages\django\core\management\__init__.py", line 367, in execute_from_command_line
utility.execute()
File "C:\Python27\lib\site-packages\django\core\management\__init__.py", line 359, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 305, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 356, in execute
output = self.handle(*args, **options)
File "C:\Python27\lib\site-packages\django\core\management\commands\migrate.py", line 202, in handle
targets, plan, fake=fake, fake_initial=fake_initial
File "C:\Python27\lib\site-packages\django\db\migrations\executor.py", line 97, in migrate
state = self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "C:\Python27\lib\site-packages\django\db\migrations\executor.py", line 132, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "C:\Python27\lib\site-packages\django\db\migrations\executor.py", line 237, in apply_migration
state = migration.apply(state, schema_editor)
File "C:\Python27\lib\site-packages\django\db\migrations\migration.py", line 129, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "C:\Python27\lib\site-packages\django\db\migrations\operations\fields.py", line 84, in database_forwards
field,
File "C:\Python27\lib\site-packages\django\db\backends\mysql\schema.py", line 43, in add_field
super(DatabaseSchemaEditor, self).add_field(model, field)
File "C:\Python27\lib\site-packages\django\db\backends\base\schema.py", line 409, in add_field
self.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\base\schema.py", line 112, in execute
cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\mysql\base.py", line 112, in execute
return self.cursor.execute(query, args)
File "C:\Python27\lib\site-packages\MySQLdb\cursors.py", line 205, in execute
self.errorhandler(self, exc, value)
File "C:\Python27\lib\site-packages\MySQLdb\connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.OperationalError: (1060, "Duplicate column name 'user_id'")
When I try to run python manage.py migrate I got errors shown above. Can anybody help me fix them?
It's a simple issue which I also faced.
It's nothing big just an issue of migrate command. Usually, when you make new models or new tables, you re-run old migrations along with the newly created ones. Of which sometimes the Django confuses I suppose over here.
Easiest solution what I found was.
1st empty your recycle bin.
then go to your migrations folder or folders( in case you have more than one app)
temporarily delete ( send all migration files such as 0001_initial.py 0002_auto_20170621_1006 etc. all of them to recycle bin.
Then re-run the commands python manage.py makemigrations and python manage.py migrate
*step 3: is temporary del. here you can also go back to recycle bin easily restore it in one click. (so del is safe)
I want to tell you my case. This only works if you be patient and you are sure about the changes.
Django 2.1
{% for crash in crashes %}
python manage.py makemigrations
Locate the conflict file (In the question catalog.0002_auto_20170219_2146.py or something)
Remove (copy in other file or don't close the file) temporally the columns that already exists into the database . (This is what you must be patient :/ ).
{% endfor %}
python manage.py migrate
Undo the change in files.
That's all, works for me.
Moral: if you found an conflict with migrate, you should fix it, dont remove all files.
There is a problem either in your DB, or your migrations, or both. If this is a new project, deleting the DB and all migrations, and recreating them with makemigrations will probably get you out of trouble.
To save your data, you can try reverting to a models.py that matches your DB, and use dumpdata to export your data to a JSON file.
How do I catch an exception in a Django migration?
I have a migration that, because of various legacy reasons, I expect to fail sometimes. I want to be able to catch that error and run some error handling code in that case.
Specifically, I'm renaming a table, and sometimes the destination table already exists and I want to merge the contents of the old and new tables, then delete the old one.
I'm running Django 1.7 ( :( ) and we're planning on upgrading to 1.8 but it hasn't happened yet.
My migration is:
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations
class Migration(migrations.Migration):
dependencies = [
('main', '0007_migration_name'),
]
operations = [
migrations.AlterModelTable(
name='table_name',
table='LegacyTableName',
),
]
When I run this, I get
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File ".../django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
File ".../django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File ".../django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File ".../django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File ".../django/core/management/commands/migrate.py", line 161, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File ".../django/db/migrations/executor.py", line 68, in migrate
self.apply_migration(migration, fake=fake)
File ".../django/db/migrations/executor.py", line 102, in apply_migration
migration.apply(project_state, schema_editor)
File ".../django/db/migrations/migration.py", line 108, in apply
operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
File ".../django/db/migrations/operations/models.py", line 236, in database_forwards
new_model._meta.db_table,
File ".../django/db/backends/schema.py", line 350, in alter_db_table
"new_table": self.quote_name(new_db_table),
File ".../django/db/backends/schema.py", line 111, in execute
cursor.execute(sql, params)
File ".../django/db/backends/utils.py", line 81, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File ".../django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File ".../django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File ".../django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File ".../django/db/backends/mysql/base.py", line 129, in execute
return self.cursor.execute(query, args)
File ".../MySQLdb/cursors.py", line 226, in execute
self.errorhandler(self, exc, value)
File ".../MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorvalue
django.db.utils.OperationalError: (1050, "Table 'LegacyTableName' already exists")
All that's provided in the migration itself is the operations list, and there doesn't seem to be an optional error-handling parameter in the docs.
How do I catch the OperationalError so I can run some Python to merge the tables?
The problem with trying to catch database exceptions in Python is that they may not be specific enough - e.g., OperationalError could arise for various reasons (only one of which is that the table name has already been changed).
I would suggest that rather than trying to catch exceptions you write your own migration function that does whatever checks/modifications are necessary. See the documentation on RunPython.
This is generally the operation you would use to create data migrations, run custom data updates and alterations, and anything else you need access to an ORM and/or Python code for.
In your case you would write a function that checks whether the table exists and performs some actions for either case.
There are some database-specific issues to be aware of when writing these functions, e.g., :
on PostgreSQL, for example, you should avoid combining schema changes and RunPython operations in the same migration or you may hit errors.
I have made changes to my model and tried to migrate the database using:
python3 manage.py makemigrations
python3 manage.py migrate
I got the following output:
vagrant#vagrant-ubuntu-trusty-64:/vagrant/grader$ python3 manage.py makemigrations
No changes detected
vagrant#vagrant-ubuntu-trusty-64:/vagrant/grader$ python3 manage.py migrate Operations to perform:
Apply all migrations: contenttypes, sessions, admin, auth, core
Running migrations:
Rendering model states... DONE
Applying core.0002_auto_20160103_0955...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 350, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 342, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 92, in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 121, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/migration.py", line 123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/operations/fields.py", line 62, in database_forwards
field,
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/schema.py", line 382, in add_field
definition, params = self.column_sql(model, field, include_default=True)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/schema.py", line 145, in column_sql
default_value = self.effective_default(field)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/schema.py", line 210, in effective_default
default = field.get_db_prep_save(default, self.connection)
File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/related.py", line 910, in get_db_prep_save
return self.target_field.get_db_prep_save(value, connection=connection)
File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", line 728, in get_db_prep_save
prepared=False)
File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", line 968, in get_db_prep_value
value = self.get_prep_value(value)
File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", line 976, in get_prep_value
return int(value)
TypeError: int() argument must be a string, a bytes-like object or a number, not 'datetime.datetime'
I don't know why the migration doesn't work. I can see that the cause is some kind of type error, but don't know what the cause is.
I figured that I would attempt to just clear the database completely as I have no relevant data in it. I planned to use:
python3 manage.py flush
python3 manage.py makemigrations
python3 manage.py migrate
But got the following output:
vagrant#vagrant-ubuntu-trusty-64:/vagrant/grader$ python3 manage.py flush
You have requested a flush of the database.
This will IRREVERSIBLY DESTROY all data currently in the 'graderdb' database,
and return each table to an empty state.
Are you sure you want to do this?
Type 'yes' to continue, or 'no' to cancel: yes
CommandError: Database graderdb couldn't be flushed. Possible reasons:
* The database isn't running or isn't configured correctly.
* At least one of the expected database tables doesn't exist.
* The SQL was invalid.
Hint: Look at the output of 'django-admin sqlflush'. That's the SQL this command wasn't able to run.
The full error: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "core_mark" references "core_student".
HINT: Truncate table "core_mark" at the same time, or use TRUNCATE ... CASCADE.
How can I completely reset a Django psql database?
As the message says, please run python3 manage.py sqlflush to see what SQL commands Django is trying to run.
Check that all tables used in the command exist in database.