On a blank MySQL database, I generated migrations for a Django 1.11 project with:
python manage.py makemigrations
I have several custom inter-dependent apps, but all the migrations generated without error. However, when I tried to apply these migrations with:
python manage.py migrate
it applies most app migrations just fine, but with some custom FeinCMS migrations with:
Applying page.0001_initial...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/backends/base/schema.py", line 93, in __exit__
self.execute(sql)
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)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 101, in execute
return self.cursor.execute(query, args)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
self.errorhandler(self, exc, value)
File "/usr/local/myproject/.env/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.IntegrityError: (1215, 'Cannot add foreign key constraint')
Unfortunately, it doesn't say which foreign key wasn't generated, and the migration has several. I tried commenting out each field in the migration re-running it, but the migration succeeds when I do it that way.
Why is this migration failing and how do I fix it?
You have an issue in Django created tables that table does not have INNODB ENGINE.
In MySql If table has INNODB ENGINE that can make relation as foreign key otherwise Django will return error as mentioned in question
"django.db.utils.IntegrityError: (1215, 'Cannot add foreign key constraint')"
I have solution for this issue.
Firstly create new management command file like name "convert_to_innodb"
and add code as below in that management command file
from django.core.management.base import BaseCommand
from django.db import connections
class Command(BaseCommand):
def handle(self, database="default", *args, **options):
cursor = connections[database].cursor()
cursor.execute("SHOW TABLE STATUS")
for row in cursor.fetchall():
if row[1] != "InnoDB":
print "Converting %s" % row[0],
print cursor.execute("ALTER TABLE %s ENGINE=INNODB" % row[0])
and RUN command in terminal
python manage.py convert_to_innodb
After this command execution you can make foreign key in already created table but
'OPTIONS': {
'init_command': 'SET default_storage_engine=INNODB',
}
add this configuration in DATABASE settings like below
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'DB_NAME',
'USER': 'DB_USER',
'PASSWORD': 'DB_PASSWORD',
'HOST': 'localhost', # Or an IP Address that your DB is hosted on
'PORT': '3306',
'OPTIONS': {
'init_command': 'SET default_storage_engine=INNODB',
}
}
}
This db configuration will create next time INNODB ENGINE table that will work for future without errors
Because of a bad merge, there were some errors in previous migrations, causing a disconnect between older migrations and the columns in my models. I fixed this by:
deleting all my migrations
truncating my django_migrations table
running manage.py makemigrations
Then migrate worked.
Related
I'm developing a large Django project and I'm beginning to write some tests. But I ran into a problem when running them. When I run python manage.py test I get the following error:
$ project/ python manage.py test
project/env/lib/python3.7/site-packages/django/db/models/base.py:319: RuntimeWarning: Model 'accounts.manager' was already registered. Reloading models is not advised as it can lead to inconsistencies, most notably with related models.
new_class._meta.apps.register_model(new_class._meta.app_label, new_class)
Creating test database for alias 'default'...
Got an error creating the test database: (1007, "Can't create database 'test_partyadvisor'; database exists")
Type 'yes' if you would like to try deleting the test database 'test_partyadvisor', or 'no' to cancel: yes
Destroying old test database for alias 'default'...
Traceback (most recent call last):
File "project/env/lib/python3.7/site-packages/django/db/backends/utils.py", line 62, in execute
return self.cursor.execute(sql)
File "project/env/lib/python3.7/site-packages/django/db/backends/mysql/base.py", line 101, in execute
return self.cursor.execute(query, args)
File "project/env/lib/python3.7/site-packages/MySQLdb/cursors.py", line 206, in execute
res = self._query(query)
File "project/env/lib/python3.7/site-packages/MySQLdb/cursors.py", line 312, in _query
db.query(q)
File "project/env/lib/python3.7/site-packages/MySQLdb/connections.py", line 224, in query
_mysql.connection.query(self, query)
MySQLdb._exceptions.OperationalError: (1170, "BLOB/TEXT column 'content' used in key specification without a key length")
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "project/env/lib/python3.7/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
utility.execute()
File "project/env/lib/python3.7/site-packages/django/core/management/__init__.py", line 356, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "project/env/lib/python3.7/site-packages/django/core/management/commands/test.py", line 29, in run_from_argv
super(Command, self).run_from_argv(argv)
File "project/env/lib/python3.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "project/env/lib/python3.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "project/env/lib/python3.7/site-packages/django/core/management/commands/test.py", line 62, in handle
failures = test_runner.run_tests(test_labels)
File "project/env/lib/python3.7/site-packages/django/test/runner.py", line 601, in run_tests
old_config = self.setup_databases()
File "project/env/lib/python3.7/site-packages/django/test/runner.py", line 546, in setup_databases
self.parallel, **kwargs
File "project/env/lib/python3.7/site-packages/django/test/utils.py", line 187, in setup_databases
serialize=connection.settings_dict.get('TEST', {}).get('SERIALIZE', True),
File "project/env/lib/python3.7/site-packages/django/db/backends/base/creation.py", line 69, in create_test_db
run_syncdb=True,
File "project/env/lib/python3.7/site-packages/django/core/management/__init__.py", line 131, in call_command
return command.execute(*args, **defaults)
File "project/env/lib/python3.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "project/env/lib/python3.7/site-packages/django/core/management/commands/migrate.py", line 204, in handle
fake_initial=fake_initial,
File "project/env/lib/python3.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 "project/env/lib/python3.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 "project/env/lib/python3.7/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
state = migration.apply(state, schema_editor)
File "project/env/lib/python3.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 "project/env/lib/python3.7/site-packages/django/db/migrations/operations/models.py", line 97, in database_forwards
schema_editor.create_model(model)
File "project/env/lib/python3.7/site-packages/django/db/backends/base/schema.py", line 319, in create_model
self.execute(sql, params or None)
File "project/env/lib/python3.7/site-packages/django/db/backends/base/schema.py", line 136, in execute
cursor.execute(sql, params)
File "project/env/lib/python3.7/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "project/env/lib/python3.7/site-packages/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "project/env/lib/python3.7/site-packages/django/utils/six.py", line 685, in reraise
raise value.with_traceback(tb)
File "project/env/lib/python3.7/site-packages/django/db/backends/utils.py", line 62, in execute
return self.cursor.execute(sql)
File "project/env/lib/python3.7/site-packages/django/db/backends/mysql/base.py", line 101, in execute
return self.cursor.execute(query, args)
File "project/env/lib/python3.7/site-packages/MySQLdb/cursors.py", line 206, in execute
res = self._query(query)
File "project/env/lib/python3.7/site-packages/MySQLdb/cursors.py", line 312, in _query
db.query(q)
File "project/env/lib/python3.7/site-packages/MySQLdb/connections.py", line 224, in query
_mysql.connection.query(self, query)
django.db.utils.OperationalError: (1170, "BLOB/TEXT column 'content' used in key specification without a key length")
The test database is created, but for some reason I can not use it (?).
My database configuration is, (in the settings.py file):
DATABASES = {
"default": {
"ENGINE": "django.db.backends.mysql",
"HOST": env.get("database").get("HOST"),
"PORT": env.get("database").get("PORT"),
"NAME": env.get("database").get("NAME"),
"USER": env.get("database").get("USER"),
"PASSWORD": env.get("database").get("PASS")
}
}
Notes:
The user I use to access the db has all grants on it.
I tried to run the tests using the root user, and got the same error.
The normal db and the cache one work perfectly.
Also ran makemigrations and migrate.
Deleted the test db from MySQL shell and re-run python manage.py test, got the same error.
Option --keep-db not working either.
System is Ubuntu 18.04 and I'm using Django 1.11 and MySQL 5.7.
In my Django project I am trying to change a database field from OneToOne to ForeignKey. When I run 'python manage.py migrate', it breaks with a long traceback ending with the warning I quoted in the title. I know others have hit this problem, but I can't find a solution that gets me around it.
I have added the following to my local_settings.py DATABASES:
'OPTIONS': {
'autocommit': True,
'charset': 'utf8mb4',
}
At first I tried simply changing OneToOne to ForeignKey but hit this problem. So I decided to do it in discrete steps by first deleting the field and later adding it with the new field type. But I can't even delete the field.
Here is the migrations file that is produced by makemigrations and is the one that migrate breaks on:
# Generated by Django 2.2.3 on 2019-07-18 09:59
from django.db import migrations
class Migration(migrations.Migration):
dependencies = [
('sweaters', '0011_auto_20190718_0954'),
]
operations = [
migrations.RemoveField(
model_name='sweater',
name='yarn_for',
),
]
Here is the full traceback I get:
$ python manage.py migrate
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes, sessions, sweaters
Running migrations:
Applying sweaters.0012_remove_sweater_yarn_for...Traceback (most recent call last):
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/utils.py", line 96, in inner
return func(*args, **kwargs)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/mysql/connector/cursor.py", line 897, in fetchall
self._handle_eof(eof)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/mysql/connector/cursor.py", line 838, in _handle_eof
self._warnings[0][1], self._warnings[0][2])
mysql.connector.errors.DatabaseError: 3719: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 15, in <module>
execute_from_command_line(sys.argv)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
utility.execute()
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/core/management/__init__.py", line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/core/management/base.py", line 323, in run_from_argv
self.execute(*args, **cmd_options)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/core/management/base.py", line 364, in execute
output = self.handle(*args, **options)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/core/management/base.py", line 83, in wrapped
res = handle_func(*args, **kwargs)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/core/management/commands/migrate.py", line 234, in handle
fake_initial=fake_initial,
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/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 "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/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 "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 245, in apply_migration
state = migration.apply(state, schema_editor)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/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 "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/migrations/operations/fields.py", line 178, in database_forwards
schema_editor.remove_field(from_model, from_model._meta.get_field(self.name))
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/backends/base/schema.py", line 479, in remove_field
fk_names = self._constraint_names(model, [field.column], foreign_key=True)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/backends/base/schema.py", line 1115, in _constraint_names
constraints = self.connection.introspection.get_constraints(cursor, model._meta.db_table)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/mysql/connector/django/introspection.py", line 320, in get_constraints
for constraint, column, ref_table, ref_column in cursor.fetchall():
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/utils.py", line 96, in inner
return func(*args, **kwargs)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/utils.py", line 89, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/django/db/utils.py", line 96, in inner
return func(*args, **kwargs)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/mysql/connector/cursor.py", line 897, in fetchall
self._handle_eof(eof)
File "/Users/frankjernigan/Documents/webdev/phrancko-web-dev/phrancko.com/phrancko-project/myenv/lib/python3.7/site-packages/mysql/connector/cursor.py", line 838, in _handle_eof
self._warnings[0][1], self._warnings[0][2])
django.db.utils.DatabaseError: (3719, "3719: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.", None)
This is an issue with MySQL switching it's default, and mysql-connector-python not being up to date. A work around is provided here:
https://code.djangoproject.com/ticket/29678
What version of mysql-connector-python are you using? I'm wondering if it might have been patched in a more recent version with the work-around in the link.
I am using Django 1.11 for making an app 'cnfs', and I am using MYSQL database with it. I am constantly facing this issue where I am getting an error like this when I type the following code:
$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.11/ref/databases/#mysql-sql-mode Operations to perform: Apply all migrations: admin, auth, cnfs, contenttypes, sites Running migrations: No migrations to apply. Traceback (most recent call last): File "manage.py", line 22, in execute_from_command_line(sys.argv) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/core/management/init.py", line 363, in execute_from_command_line utility.execute() File "/home/ubuntu/.local/lib/python2.7/site-packages/django/core/management/init.py", line 355, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/core/management/base.py", line 283, in run_from_argv self.execute(*args, **cmd_options) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/core/management/base.py", line 330, in execute output = self.handle(*args, **options) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 227, in handle self.verbosity, self.interactive, connection.alias, apps=post_migrate_apps, plan=plan, File "/home/ubuntu/.local/lib/python2.7/site-packages/django/core/management/sql.py", line 53, in emit_post_migrate_signal **kwargs File "/home/ubuntu/.local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 193, in send for receiver in self._live_receivers(sender) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/contrib/sites/management.py", line 20, in create_default_site if not Site.objects.using(using).exists(): File "/home/ubuntu/.local/lib/python2.7/site-packages/django/db/models/query.py", line 670, in exists return self.query.has_results(using=self.db) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/db/models/sql/query.py", line 517, in has_results return compiler.has_results() File "/home/ubuntu/.local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 845, in has_results return bool(self.execute_sql(SINGLE)) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 886, in execute_sql raise original_exception django.db.utils.ProgrammingError: (1146, "Table 'cnfs.django_site' doesn't exist")
I have literally spent days on this, I did not face this issue when i was using the default django database engine, sqlite3.
I have tried doing this:
$python manage.py migrate sites
My SITE_ID setting is set to 1.
I tried removing the 'django.contrib.sites' thing from the INSTALLED_APPS setting, but that throws this error:
Internal Server Error: / Traceback (most recent call last): File "/home/ubuntu/.local/lib/python2.7/site-packages/django/core/handlers/exception.py", line 41, in inner response = get_response(request) File "/home/ubuntu/.local/lib/python2.7/site-packages/django/utils/deprecation.py", line 138, in call response = self.process_request(request) File "/home/ubuntu/.local/lib/python2.7/site-packages/subdomains/middleware.py", line 62, in process_request super(SubdomainURLRoutingMiddleware, self).process_request(request) File "/home/ubuntu/.local/lib/python2.7/site-packages/subdomains/middleware.py", line 38, in process_request (self.get_domain_for_request(request), request.get_host())) File "/home/ubuntu/.local/lib/python2.7/site-packages/subdomains/middleware.py", line 31, in get_domain_for_request return get_domain() File "/home/ubuntu/.local/lib/python2.7/site-packages/subdomains/utils.py", line 12, in current_site_domain from django.contrib.sites.models import Site File "/home/ubuntu/.local/lib/python2.7/site-packages/django/contrib/sites/models.py", line 84, in class Site(models.Model): File "/home/ubuntu/.local/lib/python2.7/site-packages/django/db/models/base.py", line 118, in new "INSTALLED_APPS." % (module, name) RuntimeError: Model class django.contrib.sites.models.Site doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.
Any suggestions would be much appreciated.
Thanks.
uncomment the django.contrib.sites from installed apps
then
python manage.py migrate sites
python manage.py migrate
if you have few table in the database, drop the tables and then run this
I am using mysql. On my local machine I have 3 migrations and on the server I have nearly 9. I pushed my code + migrations to github. Pulled it on the server.
used ./manage.py migrate appname
It didn't work. Then I tried with a --merge Flag. It also didn't work! I am really new to dbms. Need help. Here 00008_merge_models is an empty migration using ./manage.py schemamigration appname --empty merge_models as given in the docs.
- Soft matched migration 0008 to 0008_merge_models.
Running migrations for appname:
- Migrating forwards to 0008_merge_models.
> appname:0002_auto__add_field_student_cv__add_field_student_status__chg_field_studen
FATAL ERROR - The following SQL query failed: ALTER TABLE `appname_student` ADD COLUMN `cv` varchar(100) NOT NULL DEFAULT '';
The error was: (1060, "Duplicate column name 'cv'")
! 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: - no dry run output for delete_foreign_key() due to dynamic DDL, sorry
= ALTER TABLE `appname_student` DROP COLUMN `cv` CASCADE; []
- no dry run output for delete_foreign_key() due to dynamic DDL, sorry
= ALTER TABLE `appname_student` DROP COLUMN `status` CASCADE; []
= DROP TABLE `appname_student_companyapplications` CASCADE; []
= DROP TABLE `appname_student_placedat` CASCADE; []
- no dry run output for alter_column() due to dynamic DDL, sorry
- no dry run output for delete_foreign_key() due to dynamic DDL, sorry
= ALTER TABLE `appname_job` DROP COLUMN `createdon` CASCADE; []
- no dry run output for alter_column() due to dynamic DDL, sorry
- no dry run output for alter_column() due to dynamic DDL, sorry
- no dry run output for alter_column() due to dynamic DDL, sorry
! 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: appname:0002_auto__add_field_student_cv__add_field_student_status__chg_field_studen
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 285, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-packages/south/management/commands/migrate.py", line 111, in handle
ignore_ghosts = ignore_ghosts,
File "/usr/local/lib/python2.7/dist-packages/south/migration/__init__.py", line 220, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "/usr/local/lib/python2.7/dist-packages/south/migration/migrators.py", line 254, in migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/usr/local/lib/python2.7/dist-packages/south/migration/migrators.py", line 329, in migrate_many
result = self.migrate(migration, database)
File "/usr/local/lib/python2.7/dist-packages/south/migration/migrators.py", line 133, in migrate
result = self.run(migration, database)
File "/usr/local/lib/python2.7/dist-packages/south/migration/migrators.py", line 114, in run
return self.run_migration(migration, database)
File "/usr/local/lib/python2.7/dist-packages/south/migration/migrators.py", line 84, in run_migration
migration_function()
File "/usr/local/lib/python2.7/dist-packages/south/migration/migrators.py", line 60, in <lambda>
return (lambda: direction(orm))
File "/home/byld/placement/placement/appname/migrations/0002_auto__add_field_student_cv__add_field_student_status__chg_field_studen.py", line 14, in forwards
keep_default=False)
File "/usr/local/lib/python2.7/dist-packages/south/db/generic.py", line 47, in _cache_clear
return func(self, table, *args, **opts)
File "/usr/local/lib/python2.7/dist-packages/south/db/generic.py", line 418, in add_column
self.execute(sql)
File "/usr/local/lib/python2.7/dist-packages/south/db/generic.py", line 282, in execute
cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/util.py", line 69, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/util.py", line 53, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 99, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/util.py", line 53, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/mysql/base.py", line 124, in execute
return self.cursor.execute(query, args)
File "/usr/local/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 205, in execute
self.errorhandler(self, exc, value)
File "/usr/local/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.OperationalError: (1060, "Duplicate column name 'cv'")
The reason why it didn't work on your server is that probably on your local machine you had different database ...
I would suggest to check what is in your sever database and what's in the models.py. When code in models.py will be equal to your database you can remove all migrations from server. Than simply use South again.
python manage.py schemamigration app --initial
python manage.py migrate app
Having trouble with the db.alter command when changing a date field from null=True and blank=True to required by removing these two values.
When the below line is commented out, the migration runs without a problem.
db.alter_column('milestones_milestone', 'date', self.gf('django.db.models.fields.DateField')(default='2011-01-01'))
This should change the column description from:
'milestones.milestone': {
'date': ('django.db.models.fields.DateField', [], {'null': 'True', 'blank': 'True'}),
},
to
'milestones.milestone': {
'date': ('django.db.models.fields.DateField', [], {default:'2011-01-01'}),
},
When the above line is left in the migration, the error I get:
- Migrating forwards to 0002_auto__add_field_milestone_type__chg_field_milestone_date__add_field_mi.
> milestones:0002_auto__add_field_milestone_type__chg_field_milestone_date__add_field_mi
! 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: = ALTER TABLE `milestones_milestone` DROP COLUMN `type` CASCADE; []
= ALTER TABLE `milestones_milestonetemplate` DROP COLUMN `type` CASCADE; []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS.
! NOTE: The error which caused the migration to fail is further up.
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_manager(global_settings)
File "C:\Python26\lib\site-packages\django\core\management\__init__.py", line 438, in execute_manager
utility.execute()
File "C:\Python26\lib\site-packages\django\core\management\__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python26\lib\site-packages\django\core\management\base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "C:\Python26\lib\site-packages\django\core\management\base.py", line 218, in execute
output = self.handle(*args, **options)
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\management\commands\migrate.py", line 109, in ha
ndle
ignore_ghosts = ignore_ghosts,
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\migration\__init__.py", line 202, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\migration\migrators.py", line 292, in migrate_ma
ny
result = self.migrate(migration, database)
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\migration\migrators.py", line 125, in migrate
result = self.run(migration)
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\migration\migrators.py", line 99, in run
return self.run_migration(migration)
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\migration\migrators.py", line 81, in run_migrati
on
migration_function()
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\migration\migrators.py", line 57, in <lambda>
return (lambda: direction(orm))
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\milestones\migrations\0002_auto__add_field_milestone_type_
_chg_field_milestone_date__add_field_mi.py", line 15, in forwards
db.alter_column('milestones_milestone', 'date', self.gf('django.db.models.fields.DateField')(default='2011-01-01'))
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\db\generic.py", line 373, in alter_column
self.execute("ALTER TABLE %s %s;" % (self.quote_name(table_name), sql), values)
File "C:\SQE_Dashboard\SQE Dashboard-mimercha\SQE Dashboard\dashboard\lib\south\db\generic.py", line 137, in execute
cursor.execute(sql, params)
File "C:\Python26\lib\site-packages\django\db\backends\util.py", line 15, in execute
return self.cursor.execute(sql, params)
File "C:\Python26\lib\site-packages\django\db\backends\mysql\base.py", line 86, in execute
return self.cursor.execute(query, args)
File "C:\Python26\lib\site-packages\MySQLdb\cursors.py", line 173, in execute
self.errorhandler(self, exc, value)
File "C:\Python26\lib\site-packages\MySQLdb\connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.DatabaseError: (1265, "Data truncated for column 'date' at row 512")
I'm using:
South 0.71 Note: I tried upgrading to 0.73 and found 0.73 gave me the same error and broke my scripts when loading older fixtures.
Django 1.2.1
python library: MySQLDdb DB API v2.0 compatible, revision 603
mysql Ver 14.14 Distrib 5.1.51, for Win32 (ia32)
InnoDB Storage Engine
I just ran into the same error. In my case I had accidentally set the column's default value to datetime.now which caused data truncation.
I'd recommend that you remove the default value from your model, set auto_now_add=True and regenerate the migration file.