I am running Django Unit tests on CircleCI with 1 container setup. The tests run fine when I do not add Django's --parallel argument. However, when I add --parallel=2 to the test run, it fails with this cryptic error below.
I've tried both versions: with and without --keepdb - both fail with exactly the same error. The code for _clode_test_db appears to suggest that passing --keepdb=True should fail fast and return. See django/db/backends/mysql/creation.py line: 29 here [https://github.com/django/django/pull/4761/files]
Would appreciate any ideas on what is going on here
Using existing clone for alias 'default' ('test_django_learned')...
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/core/management/commands/test.py", line 30, in run_from_argv
super(Command, self).run_from_argv(argv)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/core/management/commands/test.py", line 74, in execute
super(Command, self).execute(*args, **options)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/core/management/commands/test.py", line 90, in handle
failures = test_runner.run_tests(test_labels)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/test/runner.py", line 532, in run_tests
old_config = self.setup_databases()
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/test/runner.py", line 482, in setup_databases
self.parallel, **kwargs
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/test/runner.py", line 733, in setup_databases
keepdb=keepdb,
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/db/backends/base/creation.py", line 219, in clone_test_db
self._clone_test_db(number, verbosity, keepdb)
File "/home/circleci/sliderule/venv/lib/python2.7/site-packages/django/db/backends/mysql/creation.py", line 48, in _clone_test_db
dump_proc = subprocess.Popen(dump_cmd, stdout=subprocess.PIPE)
File "/usr/local/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/local/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
Exited with code 1
I could reproduce it and debugged the problem in my ubuntu container by adding
sys.stderr.write("dump_cmd: %r" % dump_cmd)
to site-packages/django/db/backends/mysql/creation.py and it gave me
dump_cmd: ['mysqldump', '--user=root', '--password=pass', '--host=db', '--port=3306', 'test']
So probably your container is also missing mysqldump which I fixed with a simple sudo apt-get install mysql-client.
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.
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
In the process of upgrading to Django 1.6 I've started to get a frequent OperationalError: (2006, 'MySQL server has gone away') message on requests to the gunicorn server I use to run the django app. These errors occur instantly from the moment the server is started, on requests that should only take a second which makes me doubt that it is a timeout issue. This error isn't present on the old 1.4 branch of the project and the 1.6 branch doesn't behave this way if it's served simply through django-admin.py runserver.
I generally run gunicorn through an sv process (though it errors if I run it manually too) with the command django-admin.py run_gunicorn --workers=4 -b localhost:8000 which results in many requests, even ones for static media, returning with:
[ERROR] 2015-07-29 14:30:27,931 - gunicorn.error:260 - Error handling request
Traceback (most recent call last):
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 125, in handle_request
respiter = self.wsgi(environ, resp.start_response)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 187, in __call__
self.load_middleware()
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 47, in load_middleware
mw_instance = mw_class()
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/middleware/locale.py", line 24, in __init__
for url_pattern in get_resolver(None).url_patterns:
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/core/urlresolvers.py", line 365, in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/core/urlresolvers.py", line 360, in urlconf_module
self._urlconf_module = import_module(self.urlconf_name)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/utils/importlib.py", line 40, in import_module
__import__(name)
File "/opt/apps/maplecroft/versions/current/websites/maplecroft/urls.py", line 2, in <module>
from maplecroft.views import RiskAtlasesLandingView
File "/opt/apps/maplecroft/versions/current/maplecroft/views.py", line 40, in <module>
import maplecroft.search as _search
File "/opt/apps/maplecroft/versions/current/maplecroft/search.py", line 71, in <module>
class MaplecroftSearchForm(SearchForm):
File "/opt/apps/maplecroft/versions/current/maplecroft/search.py", line 111, in MaplecroftSearchForm
choices=model_choices(),
File "/opt/apps/maplecroft/versions/current/maplecroft/search.py", line 57, in model_choices
for category in reversed(Category.objects.filter(parent=None)):
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/models/query.py", line 77, in __len__
self._fetch_all()
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/models/query.py", line 857, in _fetch_all
self._result_cache = list(self.iterator())
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/models/query.py", line 220, in iterator
for row in compiler.results_iter():
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 713, in results_iter
for rows in self.execute_sql(MULTI):
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 786, in execute_sql
cursor.execute(sql, params)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/backends/util.py", line 69, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/backends/util.py", line 53, in execute
return self.cursor.execute(sql, params)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/utils.py", line 99, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/backends/util.py", line 53, in execute
return self.cursor.execute(sql, params)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 124, in execute
return self.cursor.execute(query, args)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 174, in execute
self.errorhandler(self, exc, value)
File "/opt/envs/maplecroft/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
OperationalError: (2006, 'MySQL server has gone away')
However, if I drop to --workers=1 everything seems to run smoothly so my current thoughts are that it is an issue with the threaded workers feature of gunicorn?
Edit: I just tried upgrading gunicorn to the latest version (was on 0.17.2) but that doesn't seem to have made a difference.
I am wondering if this question: https://serverfault.com/questions/407612/error-2006-mysql-server-has-gone-away is relevant, but struggling to overlay it with my current issues
It appears that it was the gunicorn version after all- I tried upgrading gunicorn but was still using the django-admin.py run_gunicorn method of starting the server. Upgrading gunicorn and switching to the non-deprecated gunicorn wsgi:application method solved it.
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
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.