Django Migrations Failing - django

I have two development machines for django projects - tower and laptop. I use a private git repo to keep the projects synchronized. I work on tower for awhile, commit the changes to my git repo (including the database), then do a git pull origin master, and git reset --hard origin/master, and then I work on the laptop when I travel.
I seem to have made a mistake somewhere, as when I updated laptop as above, I have an error in my migrations. On tower, all the migrations are current and applied. On laptop, I have several migrations that cannot be applied.
[X] 0044_remove_document_rotation
[ ] 0041_remove_collectiondocument_position
[ ] 0045_merge_20191023_1922
[X] 0045_auto_20191121_1536
[ ] 0046_merge_20200213_1523
[X] 0046_auto_20200213_1541
[ ] 0047_merge_20200213_1546
These migrations are all checked on tower. I get an error when I try to migrate on laptop:
Applying memorabilia.0041_remove_collectiondocument_position...Traceback (most recent call last):
File "./manage.py", line 15, in <module>
execute_from_command_line(sys.argv)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
utility.execute()
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/core/management/__init__.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/core/management/base.py", line 328, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/core/management/base.py", line 369, in execute
output = self.handle(*args, **options)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/core/management/base.py", line 83, in wrapped
res = handle_func(*args, **kwargs)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 233, in handle
fake_initial=fake_initial,
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/db/migrations/executor.py", line 117, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/db/migrations/executor.py", line 245, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/db/migrations/migration.py", line 114, in apply
operation.state_forwards(self.app_label, project_state)
File "/home/mark/.virtualenvs/memorabilia-JSON/lib/python3.6/site-packages/django/db/migrations/operations/fields.py", line 172, in state_forwards
delay = not old_field.is_relation
AttributeError: 'NoneType' object has no attribute 'is_relation'
The project runs on both tower and laptop.
How do I get these migrations applied on laptop, or remove the ones that are causing the issues?

Have you tried to take the migrations on your laptop?
This marks migrations as applied so you won't run into trouble with them again.
Fake a single migration file:
python manage.py migrate --fake <APP_NAME> <MIGRATION>
Fake all migrations for an app:
python manage.py migrate --fake <APP_NAME>
Fake all migrations:
python manage.py migrate --fake

When I run into problems with syncing like this, as a last resort, I often remove the migrations and begin from scratch. To do this:
Create a backup of all your migrations in your migrations folder (eg. 0001.iniital.py and 0002_auto_20191220_1357.py and others like it in myproject/myproject/myapp/migrations/), and then delete them.
Go to your Django database and delete all the entries in django.migrations.
Back up your tables and then delete them from your MySQL (or other) database.
The above will give you a completely clean slate.
Thereafter:
python manage.py makemigrations
Followed by:
python manage.py migrate
If your models are set up correctly this will recreate all your structure without errors. Finally, inspect the backed up tables and, where there are no differences, replace the existing tables. Where there are differences, make sure you make the necessary data structure modifications before syncing.
I find it's often faster to do this method when dealing with a manageable database size, than to figure out the chain of what went wrong with the migrations.

Related

Django - django.core.exceptions.FieldDoesNotExist - has no field named

On our production server we got the following error when restarting django or try to run 'python manage.py makemigrations'
django.core.exceptions.FieldDoesNotExist: pricing.pricing has no field named 'price_per_hour'
What is strange is that the field price_per_hour was renamed long time ago to price and the migration when well.
But now I got this error every time and it is preventing to make any other model modification (in any app) and migrations.
What I checked :
If I run 'python manage.py showmigrations' every migration is flagged with an X, which if I'm right, means all the migration were done
price_per_hour is no longer find/used in any of the django app / class
class Pricing(models.Model):
price = models.DecimalField(default=5,max_digits=10, decimal_places=2)
class Meta:
ordering = ['-price',]
def __str__(self):
return "{}".format(self.price)
I also exported the matching./current database in sql and we well see that it contains price column and not price_per_hour. And no reference anywhere to price_per_hour
CREATE TABLE public.pricing_pricing (
id integer NOT NULL,
price numeric(10,2) NOT NULL,
);
I also tried to rename the filed price to price_per_hour just in case but it didn't help
For me it seems the error comes from Django rather than the PostgreSQL database but I'm not sure.
Here is the complete traceback
python manage.py makemigrations
Traceback (most recent call last):
File "manage.py", line 21, in <module>
main()
File "manage.py", line 17, in main
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 328, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 369, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 83, in wrapped
res = handle_func(*args, **kwargs)
File "/usr/local/lib/python3.8/site-packages/django/core/management/commands/makemigrations.py", line 141, in handle
loader.project_state(),
File "/usr/local/lib/python3.8/site-packages/django/db/migrations/loader.py", line 324, in project_state
return self.graph.make_state(nodes=nodes, at_end=at_end, real_apps=list(self.unmigrated_apps))
File "/usr/local/lib/python3.8/site-packages/django/db/migrations/graph.py", line 315, in make_state
project_state = self.nodes[node].mutate_state(project_state, preserve=False)
File "/usr/local/lib/python3.8/site-packages/django/db/migrations/migration.py", line 87, in mutate_state
operation.state_forwards(self.app_label, new_state)
File "/usr/local/lib/python3.8/site-packages/django/db/migrations/operations/fields.py", line 326, in state_forwards
raise FieldDoesNotExist(
django.core.exceptions.FieldDoesNotExist: pricing.pricing has no field named 'price_per_hour'
I don't know what other things to look for so, any idea or suggestion will be really appreciated
PS : I thought of removing all the migration files and re-running them but as this is a production server I'm afraid to lose the database content or break something.
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc" -delete
So what Boris described was the issue I had. There were incoherences in migration files and django couldn't make the migrations.
To be more precise in my case the error 'the pricing.pricing has no field named' was due to the fact that in the initial migration file the field was named price, but in the second migration file it was asked to rename price_per_hour (which didn't exist) to price and so the error
0001_initial.py
migrations.CreateModel(
name='Pricing',
fields=[
('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
('price', models.DecimalField(decimal_places=2, default=5, max_digits=10)),
0002_auto_20200304_1344.py
operations = [
migrations.RenameField(
model_name='pricing',
old_name='price_per_hour',
new_name='price',
),
So both options described by Boris are those to follow. First you can try to go through all migrations files and hopefully find and fix manually the error.
To find out which one caused trouble I did this https://stackoverflow.com/a/53135777/20025351
And if you cannot fix it manually (that was my case) I made sure to have the database model matching the Django models, then I removed all the migrations files and re-run migration/migrate.
The error is found on the row migrations/operations/fields. Somehow a discrepancy between the database and the migrations files has occurred, or perhaps you applied a RunPython command in your migration file that references to this field.
I also faced a similar issues, and in my case it appeared to be a creation and deletion of a specific field in two old migration files that seemed to be the issue.
The solution for you is to 'fix' the old migration files, or squash your history.
Option 1) Fixing the error would require you to go through all migrations files and manually edit the migrations where this error stems from. If you can run the makemigration command in your local editor in debug mode you can track where this error occurs. Sadly Django's errorhanding on these errors are not that detailed.
Option 2) An easier option, the option which I would go for, is to squash the migration files. You thus remove all the history of the migration files, and reduce it to a single migration step. See docs. A downside is that you lose all your history, so make sure your local, staging and production environment is all synced up. Specifically on production, make sure that the database model (if you use postgres you can use pgadmin) is exactly the same as your Django model seen in the code.
Squashing the migration files actually removes the whole history. In your example, if you have a migration to add a field price_per_hour, and one to rename that field later to price, squashing will merge those migration files into a single action that makes the field price.

Django can't makemigrations after changing app name and db tables

I'm working with Django 1.11.5 and using PyCharm as my IDE. I've been trying to refactor my app name from "clinicaltrials" to "cancer_trials". PyCharm updated all of my project files accordingly. I then followed the steps in this SO answer to update the appropriate database tables. However, I'm getting the following error when I try run makemigration. I can't seem to figure out what this means and/or what part I'm missing here.
> python manage.py makemigrations
Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "C:\Python_3.6.1\lib\site-packages\django\core\management\__init__.py", line 364, in execute_from_command_line
utility.execute()
File "C:\Python_3.6.1\lib\site-packages\django\core\management\__init__.py", line 356, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python_3.6.1\lib\site-packages\django\core\management\base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Python_3.6.1\lib\site-packages\django\core\management\base.py", line 330, in execute
output = self.handle(*args, **options)
File "C:\Python_3.6.1\lib\site-packages\django\core\management\commands\makemigrations.py", line 150, in handle
loader.project_state(),
File "C:\Python_3.6.1\lib\site-packages\django\db\migrations\loader.py", line 323, in project_state
return self.graph.make_state(nodes=nodes, at_end=at_end, real_apps=list(self.unmigrated_apps))
File "C:\Python_3.6.1\lib\site-packages\django\db\migrations\graph.py", line 409, in make_state
project_state = self.nodes[node].mutate_state(project_state, preserve=False)
File "C:\Python_3.6.1\lib\site-packages\django\db\migrations\migration.py", line 92, in mutate_state
operation.state_forwards(self.app_label, new_state)
File "C:\Python_3.6.1\lib\site-packages\django\db\migrations\operations\fields.py", line 142, in state_forwards
for name, instance in state.models[app_label, self.model_name_lower].fields:
KeyError: ('cancer_trials', 'cancer_trials')
Here's the function that's throwing the error
def state_forwards(self, app_label, state):
new_fields = []
old_field = None
for name, instance in state.models[app_label, self.model_name_lower].fields:
if name != self.name:
new_fields.append((name, instance))
else:
old_field = instance
state.models[app_label, self.model_name_lower].fields = new_fields
# Delay rendering of relationships if it's not a relational field
delay = not old_field.is_relation
state.reload_model(app_label, self.model_name_lower, delay=delay)
In my experience the easiest solution is to create new app and copy the code:
Create new app with the desired name and add it to settings
Copy/paste code from old app to new app, change references from old app to new app, run makemigrations and migrate
Open database and copy data from old tables to new tables
Check that everything works in new app
Search stackoverflow.com or google how to remove app from project or just leave in there. Unfortunately, I'm not 100 % positive about these steps, somebody please correct me if I'm wrong, but to my recollection:
run python manage.py migrate old_app zero (this unapplies all migrations for an app)
remove app from settings
delete files
Remove the all migrations files within your project
Go through each of your projects apps migration folder and remove everything inside, except the init.py file.
Drop the current database, or delete the db.sqlite3 if it is your case.
Create the initial migrations and generate the database schema
try run again migrationsa and migrate commans
OK
if you want to keep the existing database maybe this guide may help you:
https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html
(scenario 2)
A nice answer on how to properly move data between apps, can be found here.
What worked for me is the following:
Export the data to json
./manage.py dumpdata --exclude auth.permission --exclude contenttypes --exclude admin.LogEntry --exclude sessions --indent 2 > <path_out_of_the_project>/db.json
Open the db.json file using a capable editor and rename all the instances of the old app name to the new app name.
Rename your app and all the necessary references into your code.
Delete the database and recreate a new empty one applying all the migrations.
Load the data from the db.json file which include the new app name.
./manage.py loaddata <path_out_of_the_project>/db.json
simple approach:
Manually delete all migrations in the apps by going into each apps' 'Migrations' named directory.
Note: deleting init.py in 'Migrations' named directory will not cause any harm.
Above 'appname' is apps taken one-by-one and migrated using above steps. For new apps added will only show migrated table for the next two 'migrate' and 'sqlmigrate' command work.
After this:
$: python manage.py makemigrations appname
$: python manage.py migrate appname
$: python manage.py sqlmigrate appname 0001

Setting up dj-stripe (initial migrations) ProgrammingError: relation "djstripe_customer" does not exist

dj-stripe looks like a very attractive way to manage stripe subscriptions with django.
I installed dj-stripe following the instructions here.
Installation seemed to work, in that the installation includes running these three commands, and doing so created and populated new tables in my Postgres DB as well as creating new customer objects in my stripe account.
python manage.py migrate
python manage.py djstripe_init_customers
python manage.py djstripe_init_plans
For some reason, I decided dj-stripe was overkill (stripe's api seems easy enough to use without so much boilerplate) so I uninstalled using (pip uninstall dj-stripe), removed the mention from INSTALLED_APPS and the entry in urls.py.
To finish the clean-up, I deleted the customers which had been created in my stripe.com account, then I used DROP TABLE to manually delete the leftover tables in my Postgres DB (all tables starting with djstripe_: tables like djstripe_customer, djstripe_invoice, etc.)
Now, I've decided I actually do want to use dj-stripe, but this time installation is not working. The second of those three commands throws a ProgrammingError
requirements.txt includes:
stripe==1.22.3
dj-stripe==0.5.0
Installed dj-stripe using pip...
pip install -r requirements.txt
...and received success messages.
Then following on instructions as before, I ran into a ProgrammingError.
(awe01)MoriartyMacBookAir13:awesomeapp macuser$ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: django_user_agents, evernote, twitter, polls, widget_tweaks, djrill, sitemaps, facebook, django_slack, storages, hello
Apply all migrations: account, djstripe, admin, sessions, sites, auth, audiotracks, contenttypes, socialaccount
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
No migrations to apply.
(I'm not sure what the above was supposed to achieve...
At this point I checked my postgres db: no extra tables have been created. There is no table with name starting with djstripe_)
(awe01)MoriartyMacBookAir13:awesomeapp macuser$ python manage.py djstripe_init_customers
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/djstripe/management/commands/djstripe_init_customers.py", line 15, in handle
for subscriber in get_subscriber_model().objects.filter(customer__isnull=True):
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/models/query.py", line 141, in __iter__
self._fetch_all()
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/models/query.py", line 966, in _fetch_all
self._result_cache = list(self.iterator())
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/models/query.py", line 265, in iterator
for row in compiler.results_iter():
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 700, in results_iter
for rows in self.execute_sql(MULTI):
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 786, in execute_sql
cursor.execute(sql, params)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/backends/utils.py", line 81, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/Users/macuser/Dropbox/code/hero/awes01/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "djstripe_customer" does not exist
LINE 1: ...r"."date_joined" FROM "auth_user" LEFT OUTER JOIN "djstripe_...
The error
for subscriber in get_subscriber_model().objects.filter(customer__isnull=True):
referrs to line 15 of djstripe_init_customers.py
I don't understand why the normal migration steps are failing (why it expects "djstripe_customer" to have been created before it has been). Grateful for steps I can take to further trouble-shoot. (I'm assuming I've created the gotcha due to dirty uninstall of initial attempt?)
In case relevant:
My auth system is django-allauth
AUTH_USER_MODEL is not explicitly defined in my settings.py file and has been working fine. (I didn't make a custom user model.)
#kavanaugh-development solved this:
To completely remove remnant of the initial install, I had to remove the relevant djstripe rows from the migrations table. "If you don't delete those rows, django will ignore the migration commands the second time around."
DELETE FROM django_migrations WHERE app = 'djstripe';
Once I had done this, a fresh install of dj-stripe worked perfectly as it did the first time round:
I ran python manage.py migrate, which
re-created a few djstripe rows in django_migrations table
also created (empty) tables required for dj-stripe:
djstripe_charge
djstripe_charge_id_seq
djstripe_currentsubscription
djstripe_currentsubscription_id_seq
djstripe_customer
djstripe_customer_id_seq
djstripe_event
djstripe_event_id_seq
djstripe_eventprocessingexception
djstripe_eventprocessingexception_id_seq
djstripe_invoice
djstripe_invoice_id_seq
djstripe_invoiceitem
djstripe_invoiceitem_id_seq
djstripe_plan
djstripe_plan_id_seq
djstripe_transfer
djstripe_transfer_id_seq
djstripe_transferchargefee
djstripe_transferchargefee_id_seq
So the required tables are ready to be populated by the subsequent commands
(such as python manage.py djstripe_init_customers)
So that's a general (basic) lesson learned about migrations; hope this helps someone.
Thanks

Why are celery_taskmeta and other tables not being created when running a syncdb in django?

I'm trying to setup celery and django, but the celery_taskmeta table is not being created.
I've followed numerous (Recent) tutorials, added djcelery and djkombu to my installed_apps. added the 'BROKER_TRANSPORT = "djkombu.transport.DatabaseTransport"' line to my settings, etc.
I can run the daemon just fine, and it will execute tasks, but it spits out this traceback at the end:
==============
2011-08-05 16:21:16,231: ERROR/MainProcess] Task slate.modules.filebrowser.tasks.gen_thumb_task[0afc564b-cc54-4f4c-83f5-6db56fb23b76] raised exception: DatabaseError('no such table: celery_taskmeta',)
Traceback (most recent call last):
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/celery/worker/job.py", line 107, in execute_safe
return self.execute(*args, **kwargs)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/celery/worker/job.py", line 125, in execute
return super(WorkerTaskTrace, self).execute()
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/celery/execute/trace.py", line 79, in execute
retval = self._trace()
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/celery/execute/trace.py", line 93, in _trace
r = handler(trace.retval, trace.exc_type, trace.tb, trace.strtb)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/celery/worker/job.py", line 140, in handle_success
self.task.backend.mark_as_done(self.task_id, retval)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/celery/backends/base.py", line 54, in mark_as_done
return self.store_result(task_id, result, status=states.SUCCESS)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/celery/backends/base.py", line 194, in store_result
return self._store_result(task_id, result, status, traceback, **kwargs)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/djcelery/backends/database.py", line 20, in _store_result
traceback=traceback)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/djcelery/managers.py", line 36, in _inner
return fun(*args, **kwargs)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/djcelery/managers.py", line 154, in store_result
"traceback": traceback})
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/djcelery/managers.py", line 78, in update_or_create
return self.get_query_set().update_or_create(**kwargs)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/djcelery/managers.py", line 62, in update_or_create
obj, created = self.get_or_create(**kwargs)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/django/db/models/query.py", line 378, in get_or_create
return self.get(**lookup), False
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/django/db/models/query.py", line 344, in get
num = len(clone)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/django/db/models/query.py", line 82, in __len__
self._result_cache = list(self.iterator())
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/django/db/models/query.py", line 273, in iterator
for row in compiler.results_iter():
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 680, in results_iter
for rows in self.execute_sql(MULTI):
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql
cursor.execute(sql, params)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site- packages/django/db/backends/util.py", line 34, in execute
return self.cursor.execute(sql, params)
File "/Users/erichutchinson/python-env/slate/lib/python2.7/site- packages/django/db/backends/sqlite3/base.py", line 234, in execute
return Database.Cursor.execute(self, query, params)
DatabaseError: no such table: celery_taskmeta
-============================
so how the hell do i get this table created during syncdb?
The problem here is actually that South manages the djcelery tables. You need to migrate djcelery to it's new schema. If you upgraded djcelery from an earlier version and you already have a set of tables installed, you need to do a fake migration first:
python manage.py migrate djcelery 0001 --fake
python manage.py migrate djcelery
I had the same problems before but this fixed it.
I was also getting the following error:
DatabaseError: no such table: djkombu_queue
After looking into it a bit further I believe the correct way to solve this problem (pulled from here) it to add the following to INSTALLED_APPS:
INSTALLED_APPS = ('djcelery.transport', )
Adding kombu.transport.django felt incorrect.
Ran into the exact same issue, fresh install. Downgrading celery and django-celery to 2.2.7 and rerunning syncdb solved it (for the interim, anyway).
I was getting a similar error:
DatabaseError: no such table: djkombu_queue
In my case, I needed to add a Django app from a related technology to the INSTALLED_APPS setting. In my case, it was: kombu.transport.django
After that, I reran syncdb and everything was working. In your case, maybe add something in the celery egg to the path.
I got this error while running manage.py dumpdata. I tried two different 2.2.x versions of the celery and django-celery packages with a MySQL database. In my case upgrading to 2.2.7 didn't fix the issue. What did work was advice found on this Github Issue #34.
When using dumpdata on Django 1.3+, add the --exclude djcelery option. (Of course, if you are dumping only a subset of apps and models you won't get the missing table error anyway. And if you aren't using dumpdata in the first place, this answer doesn't apply.)
The problem is probably SQLite3. You can not use it concurrently in Django and it is throwing an misleading error. Switch to PostgreSQL or MySQL, especially for celeryd development.
Or, bite the bullet, and setup RabbitMQ ...

how Update column data type in Django

I have new to python and django I am creating poll application and in that application after creating models poll and choice using "South". I want to changer the length of question field from 200 to 300 but I am not able to achieve it even using south as well.
I have run python manage.py schemamigration polls --initial command to create migration file then I make change in poll question field that is (question = models.CharField(max_length=250)) change max_length from 200 to 250.
and the again run python manage.py schemamigration polls --auto this will generate new migration file.
after that all stuff I run python manage.py migrate polls and it shows following error :
C:\Python26\lib\site-packages\MySQLdb\__init__.py:34: DeprecationWarning: the sets module is deprecated
from sets import ImmutableSet
Running migrations for polls:
- Migrating forwards to 0003_auto__chg_field_poll_question.
> polls:0003_auto__chg_field_poll_question
! 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 `polls_poll` ; []
= ALTER TABLE `polls_poll` MODIFY `question` varchar(200) NOT NULL;; []
= ALTER TABLE `polls_poll` ALTER COLUMN `question` DROP DEFAULT; []
! 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(settings)
File "C:\Python26\lib\site-packages\django\core\management\__init__.py", line
362, in execute_manager
utility.execute()
File "C:\Python26\lib\site-packages\django\core\management\__init__.py", line
303, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python26\lib\site-packages\django\core\management\base.py", line 195,
in run_from_argv
self.execute(*args, **options.__dict__)
File "C:\Python26\lib\site-packages\django\core\management\base.py", line 222,
in execute
output = self.handle(*args, **options)
File "C:\Python26\lib\site-packages\south\management\commands\migrate.py", lin
e 109, in handle
ignore_ghosts = ignore_ghosts,
File "C:\Python26\lib\site-packages\south\migration\__init__.py", line 202, in
migrate_app
success = migrator.migrate_many(target, workplan, database)
File "C:\Python26\lib\site-packages\south\migration\migrators.py", line 220, i
n migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, datab
ase)
File "C:\Python26\lib\site-packages\south\migration\migrators.py", line 291, i
n migrate_many
result = self.migrate(migration, database)
File "C:\Python26\lib\site-packages\south\migration\migrators.py", line 125, i
n migrate
result = self.run(migration)
File "C:\Python26\lib\site-packages\south\migration\migrators.py", line 99, in
run
return self.run_migration(migration)
File "C:\Python26\lib\site-packages\south\migration\migrators.py", line 81, in
run_migration
migration_function()
File "C:\Python26\lib\site-packages\south\migration\migrators.py", line 57, in
<lambda>
return (lambda: direction(orm))
File "C:\mysite\..\mysite\polls\migrations\0003_auto__chg_field_poll_question.
py", line 12, in forwards
db.alter_column('polls_poll', 'question', self.gf('django.db.models.fields.C
harField')(max_length=250))
File "C:\Python26\lib\site-packages\south\db\generic.py", line 330, in alter_c
olumn
self.delete_foreign_key(table_name, name)
File "C:\Python26\lib\site-packages\south\db\generic.py", line 588, in delete_
foreign_key
constraints = list(self._constraints_affecting_columns(table_name, [column],
"FOREIGN KEY"))
File "C:\Python26\lib\site-packages\south\db\mysql.py", line 140, in _constrai
nts_affecting_columns
""", [db_name, table_name, type])
File "C:\Python26\lib\site-packages\south\db\generic.py", line 134, in execute
cursor.execute(sql, params)
File "C:\Python26\lib\site-packages\django\db\backends\util.py", line 19, in e
xecute
return self.cursor.execute(sql, params)
File "C:\Python26\lib\site-packages\django\db\backends\mysql\base.py", line 84
, in execute
return self.cursor.execute(query, args)
File "C:\Python26\lib\site-packages\MySQLdb\cursors.py", line 168, in execute
if not self._defer_warnings: self._warning_check()
File "C:\Python26\lib\site-packages\MySQLdb\cursors.py", line 82, in _warning_
check
warn(w[-1], self.Warning, 3)
_mysql_exceptions.Warning: Can't find file: 'slow_log' (errno: 2)
Please help me
0003 Look like :
class Migration(SchemaMigration):
def forwards(self, orm):
# Changing field 'Poll.question'
db.alter_column('polls_poll', 'question', self.gf('django.db.models.fields.CharField')(max_length=250))
def backwards(self, orm):
# Changing field 'Poll.question'
db.alter_column('polls_poll', 'question', self.gf('django.db.models.fields.CharField')(max_length=200))
Ansh J
Go modify the mysql table from the mysql console already!
python manage.py dbshell
alter table appname_modelname modify `question` varchar(200) NOT NULL;
To be able to answer this question with any certainty you'll need to show migrations 0002 and 0003...
However, it seems to me the resulting exception is simply a problem with MySQL (it cannot find its 'slow log') that creates a warning that is propagated to south, which trips over it.
The problem you're having is not in Django or South, it's in MySQL. MySQL is coughing up the following:
_mysql_exceptions.Warning: Can't find file: 'slow_log' (errno: 2)
and it's panicking the MySQLdb library, which is triggering the bailout, even though it's just a warning.
You need to find out why MySQL is so concerned about its missing slow_log file.
I suspect that you likely have general_log and slow_log frm files within
the mysql database directory, without any corresponding data files. If
this is the case then just 'rm' the general_log.frm and slow_log.frm
files from the mysql database directory, and all these errors should go
away.