Having problems migrating in South - mysql

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

Related

Migrate fails on warning "'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release'

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.

Unable to generate migrations in Django 1.11

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.

1146 "app_name.django_site missing"

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

Django: "Unknown Column" when run makemigrations on an app after adding an Integer Field

First of all, I have recently upgraded from Django 1.6 to 1.8, and never used South, so I'm new to migrations.
I just ran:
> python manage.py makemigrations myapp
> python manage.py migrate --fake initial
to create the initial migrations for my model with existing MySQL tables. All seemed good so far.
I then added an IntegerField to my model:
new_integer_field = models.IntegerField(default = 50) #can include blank=True, null=True; seems to make no difference
Now when I run:
>python manage.py makemigrations myapp
I get
django.db.utils.OperationalError: (1054, "Unknown column 'myapp_mymodel.new_integer_field' in 'field list'")
The traceback (starting where the problem occured) is:
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 338, in execute_from_command_line
utility.execute()
File ".../django/core/management/__init__.py", line 312, in execute
django.setup()
File ".../django/__init__.py", line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File ".../django/apps/registry.py", line 115, in populate
app_config.ready()
File ".../autocomplete_light/apps.py", line 9, in ready
autodiscover()
File ".../autocomplete_light/registry.py", line 298, in autodiscover
autodiscover_modules('autocomplete_light_registry')
File ".../django/utils/module_loading.py", line 74, in autodiscover_modules
import_module('%s.%s' % (app_config.name, module_to_search))
File ".../python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
File ".../mymapp/autocomplete_light_registry.py", line 42, in <module>
x = other_model.other_model_manager.manager_function(),
File ".../myapp/models.py", line 759, in get_a_queryset
stus = a_queryset
File ".../myapp/models.py", line 92, in get_another_queryset
if obj.model_function(prog):
File ".../myapp/models.py", line 402, in model_function
z = object.MyManagerObjects.manager_function(self)
File ".../myapp/models.py", line 573, in get_type
curstart = mymodel.MyManagerObjects.get().old_field
File ".../python2.7/site-packages/django/db/models/manager.py", line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File ".../python2.7/site-packages/django/db/models/query.py", line 328, in get
num = len(clone)
File ".../python2.7/site-packages/django/db/models/query.py", line 144, in __len__
self._fetch_all()
File ".../python2.7/site-packages/django/db/models/query.py", line 965, in _fetch_all
self._result_cache = list(self.iterator())
File ".../python2.7/site-packages/django/db/models/query.py", line 238, in iterator
results = compiler.execute_sql()
File ".../python2.7/site-packages/django/db/models/sql/compiler.py", line 840, in execute_sql
cursor.execute(sql, params)
File ".../python2.7/site-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File ".../python2.7/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File ".../python2.7/site-packages/django/db/utils.py", line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File ".../python2.7/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File ".../python2.7/site-packages/django/db/backends/mysql/base.py", line 124, in execute
return self.cursor.execute(query, args)
File ".../python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
self.errorhandler(self, exc, value)
File ".../python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.OperationalError: (1054, "Unknown column 'myapp_mymodel.new_integer_field' in 'field list'")
MyManager is simple, as follows:
class MyManager(models.Manager):
def get_queryset(self):
return super(MyManager, self).get_queryset().filter(...some filters...) #this is guaranteed to return a queryset with one object in it.
And inside myapp/models.py:
MyManagerObjects = MyManager()
So, my question is, why can't I add a field to mymodel and run makemigrations? What is breaking in the manager? I'm starting the stacktrace there because I've tried a variety of different commenting out strategies that seem to point to this manager regardless of what the prior calls are.
I'm sure hoping someone can tell me it's something quick and simple that I'm just not seeing, but I'm not sure how that will be the case! Anyone else had this trouble or have any suggestions?
----****----
Update 1: the error doesn't just occur with makemigrations - since some commentors asked what happens when I run python manage.py migrate I thought I'd try it for things and giggles, even though there is nothing to migrate. I was expecting to be told there was nothing to migrate, but I got the same error. So it's not makemigrations code itself; it's something not able to function because it can't find the new field.
Somehow it is looking at the model and finding a field that it doesn't recognize. But why?!
----****----
Update 2: I added the start of the traceback... I'm loathe to post any of the actual paths/model names, hence the edits. Hope that's ok. A note - it is not, as far as I can tell, related to autocomplete_light (unless it is!) because when I comment out the line x = other_model.other_model_manager.manager_function() (line 42 in autocomplete_light_registry.py) the error occurs without reference to autocomplete_light. I've added a second traceback here in case that helps too!
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 338, in execute_from_command_line
utility.execute()
File ".../django/core/management/__init__.py", line 312, in execute
django.setup()
File ".../django/__init__.py", line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File ".../django/apps/registry.py", line 115, in populate
app_config.ready()
File ".../django/contrib/admin/apps.py", line 22, in ready
self.module.autodiscover()
File ".../django/contrib/admin/__init__.py", line 24, in autodiscover
autodiscover_modules('admin', register_to=site)
File ".../django/utils/module_loading.py", line 74, in autodiscover_modules
import_module('%s.%s' % (app_config.name, module_to_search))
File ".../python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
File ".../myapp/admin.py", line 151, in <module>
class MyListFilter(SimpleListFilterWithDefault):
File ".../myapp/admin.py", line 154, in MyListFilter
x = mymodel.MyManagerObjects.get()
File ".../django/db/models/manager.py", line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File ".../django/db/models/query.py", line 328, in get
num = len(clone)
File ".../django/db/models/query.py", line 144, in __len__
self._fetch_all()
File ".../django/db/models/query.py", line 965, in _fetch_all
self._result_cache = list(self.iterator())
File ".../django/db/models/query.py", line 238, in iterator
results = compiler.execute_sql()
File ".../django/db/models/sql/compiler.py", line 840, in execute_sql
cursor.execute(sql, params)
File ".../django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File ".../django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File ".../django/db/utils.py", line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File ".../django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File ".../django/db/backends/mysql/base.py", line 124, in execute
return self.cursor.execute(query, args)
File ".../MySQLdb/cursors.py", line 205, in execute
self.errorhandler(self, exc, value)
File ".../MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.OperationalError: (1054, "Unknown column 'myapp_mymodel.new_integer_field' in 'field list'")
It looks like you are making a db query either when your module is imported or when the app is being registered:
curstart = mymodel.MyManagerObjects.get().old_field
This means when you run any management command like runserver, makemigrations or migrate, if you've changed your models then they will be out of sync with your database, and making the query will throw an exception before the command can do what it's supposed to (like make your migrations).
If possible, modify your code so MyManagerObjects.get() isn't called at load time, eg by using a lambda function or wrapping it in a method that you can call at run time.
If that's not possible, you'll need to comment out that section of the code every time you make or run migrations, but that's really messy.
Update:
In the full traceback there's the line:
File ".../myapp/admin.py", line 154, in MyListFilter
x = mymodel.MyManagerObjects.get()
which means the get is being run when the admin file is imported. I think you may need to put the call to mymodel.MyManagerObjects.get() in MyListFilter.queryset() instead of in the class declaration.
https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_filter
It shouldn't be:
python manage.py makemigrations mymodel
it should be:
python manage.py makemigrations myapp
So comment out new_integer_field and do it again I think.
You also need to run migrate to add the new_integer_fieldcolumn in the database table.
python manage.py makemigrations myapp
./manage.py migrate --fake
# add new_integer_field
./manage.py makemigrations myapp
./manage.py migrate

Django South - db.alter function removing null=true blank=true fails with mysql

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.