Not sure why django South is trying to run reverse migration - mysql

When I run python manage.py migrate api it fails with "RuntimeError: Cannot reverse this migration."
The problem is, I'm not sure why it would even be trying to run a reverse migration? The file its failing on is 0025, which isn't mentioned in the south_migrationhistory table in the MySQL database.
Any ideas why South would be trying to run a reverse migration with this command?
Thanks!
EDIT:
The full stack trace is:
Running migrations for api:
- Migrating forwards to 0026_auto.
> api:0025_auto__chg_field_article_curator_response_comment__chg_field_article_cu
Traceback (most recent call last):
File "manage.py", line 14, in <module> execute_manager(settings)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 459, in execute_manager utility.execute()
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 382, in execute self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv self.execute(*args, **options.__dict__)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute output = self.handle(*args, **options)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/management/commands/migrate.py", line 105, in handle ignore_ghosts = ignore_ghosts,
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/__init__.py", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 292, in migrate_many result = self.migrate(migration, database)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 125, in migrate result = self.run(migration)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 99, in run return self.run_migration(migration)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 86, in run_migration print self.run_migration_error(migration)
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 286, in run_migration_error (self.format_backwards(migration), extra_info))
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 273, in format_backwards self.backwards(migration)()
File "/home/ubuntu/fake-env/local/lib/python2.7/site-packages/south/migration/migrators.py", line 57, in <lambda> return (lambda: direction(orm))
File "/home/ubuntu/fakeapi/fakeapi/../fakeapi/api/migrations/0025_auto__chg_field_article_curator_response_comment__chg_field_article_cu.py", line 42, in backwards raise RuntimeError("Cannot reverse this migration. 'Image.article' and its values cannot be restored.")
RuntimeError: Cannot reverse this migration. 'Image.article' and its values cannot be restored.

It has encountered a migration error, and tries to rollback it. You can clean up backwards migration temporarily and look what is the real error.

Related

Django can not create test database using MySQL

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.

Table 'auth_user' already exits , when I try to migrate new tables to my local mysql database

I am trying to deploy a Django project on my local machine.As far as I know, when I run migrate command, my_app tables along with django's table should be visible in my local database. When I run makemigration app_name command, I can see the correct SQL query is generated for my table. However, when I run migrate command, I get the error
table 'auth_user' already exists
My database is empty before I run this.
Also my migration folder has just the init.py file.
Following is the Error Log i get:
$ python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, impact_mapping, sessions
Running migrations:
Applying impact_mapping.0001_initial...Traceback (most recent call last):
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\utils.py", line 62, in execute
return self.cursor.execute(sql)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\mysql\base.py", line 101, in execute
return self.cursor.execute(query, args)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\MySQLdb\cursors.py", line 209, in execute
res = self._query(query)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\MySQLdb\cursors.py", line 315, in _query
db.query(q)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\MySQLdb\connections.py", line 226, in query
_mysql.connection.query(self, query)
MySQLdb._exceptions.OperationalError: (1050, "Table 'auth_user' already exists")
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 "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\core\management\__init__.py", line 364, in execute_from_command_line
utility.execute()
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\core\management\__init__.py", line 356, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\core\management\base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\core\management\base.py", line 330, in execute
output = self.handle(*args, **options)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\core\management\commands\migrate.py", line 204, in handle
fake_initial=fake_initial,
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\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 "C:\Users\dpanch378\CBAT\component_mapping\env\lib\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 "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\migrations\executor.py", line 244, in apply_migration
state = migration.apply(state, schema_editor)
File "C:\Users\dpanch378\CBAT\component_mapping\env\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:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\migrations\operations\models.py", line 97, in database_forwards
schema_editor.create_model(model)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\base\schema.py", line 319, in create_model
self.execute(sql, params or None)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\base\schema.py", line 136, in execute
cursor.execute(sql, params)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\utils\six.py", line 685, in reraise
raise value.with_traceback(tb)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\utils.py", line 62, in execute
return self.cursor.execute(sql)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\django\db\backends\mysql\base.py", line 101, in execute
return self.cursor.execute(query, args)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\MySQLdb\cursors.py", line 209, in execute
res = self._query(query)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\MySQLdb\cursors.py", line 315, in _query
db.query(q)
File "C:\Users\dpanch378\CBAT\component_mapping\env\lib\site-packages\MySQLdb\connections.py", line 226, in query
_mysql.connection.query(self, query)
django.db.utils.OperationalError: (1050, "Table 'auth_user' already exists")
(env)
Expected Outcome:I should get all the tables in my database
Actual Outcome: I get the error that auth_user table already exists.

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 Error code 28 while synchronizing the database (MySQL)

In django I create new models in existing database. While synchronizing the models it displays an error. I cannot fix these problem. I'm using mysql as database. I added the error code. Kindly share your ideas.
python manage.py syncdb
Creating tables ...
Creating table registration_securityquestions
Traceback (most recent call last):
File "manage.py", line 14, in <module>
execute_manager(settings)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 459, in execute_manager
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 382, 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 196, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 232, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 371, in handle
return self.handle_noargs(**options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/syncdb.py", line 102, in handle_noargs
cursor.execute(statement)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/util.py", line 40, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/mysql/base.py", line 114, in execute
return self.cursor.execute(query, args)
File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute
self.errorhandler(self, exc, value)
File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.DatabaseError: (3, "Error writing file './userregdb/registration_securityquestions.frm' (Errcode: 28)")
From the MySQL doc:
The preceding error is a typical message for Windows; the Unix message is similar.
One fix is to start mysqld with the --tmpdir option or to add the option to the [mysqld] section of your option file. For example, to specify a directory of C:\temp, use these lines:
[mysqld]
tmpdir=C:/temp

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.