I am working on a django app and was using south for migrations. Everything worked well in my system and I was able to migrate. But when I put the code in the server and ran syncdb, I got the error as:
#After a long traceback
from django.db.models.loading import cache
Import Error: no module named cache
Then I removed south from the installed_apps and tried syncdb, which worked perfectly. But import south works fine in shell. So I am sure that south is installed in my server. Why do I get this error?
edit: The same error occured in some other systems too. I install south using pip install south
In the comments you mention you are using Django 1.7.
I wouldn't imagine South to support that version, as South-like migration support (by the South author, no less) lands in 1.7: https://docs.djangoproject.com/en/dev/topics/migrations/
Related
We have migrated the Django 1.4 application to Django 1.8 successfully. The Django 1.4 version of applicaiton is still in use in production until we go live with Django 1.8. The problem is that lots of data have been updated on production server which needs to be migrated to version 1.8. Is there any way I can migrate the data from database of 1.4 to 1.8 except manually doing that? Note that the model/database columns are different in both the version.
Can anybody suggest some good options ?
Thanks.
Required pre-reading
Django migrations:
https://docs.djangoproject.com/en/1.8/ref/django-admin/#makemigrations-app-label
Assuming you were using South:
https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south
Getting Started
Firstly dump your local database I prefer using mysql/postgres/whatever docs for this rather than using ./manage.py dumpdata.
You will also want to dump your production database as well just for safekeeping.
Next in your local environment I would dump the database and create a new database.
Then I would test that all your migrations actually work on a blank database.
These are the instructions for django 1.8
./manage.py makemirgrations
./manage.py migrate
That will help show up if any migrations are in an inconsistent state operating from a blank slate. If you encounter any errors they should be fixed first.
Given that works, now I would test that your migrations actually work against your production data.
So drop your local database, create a fresh one then load the production dump in.
If the tables are already configured correctly (i.e. they are in an up to date state in your production database) then you will need to fake all migrations.
./manage.py migrate --fake <appname>
However given that you have changed some models since upgrading to 1.8 in your local environment, then you might need to fake only some of the migrations. This could be the tricky part depending on the timing of when you upgraded and when you created the migrations.
Because django 1.7 will just create an initial migration for each app, you may need to actually break up the migration for some apps. That is, instead of 0001_initial you might need to manually break up that migration into 2 components:
1. a migration to match the current state of your production database
2. a migration to match any additional changes you have made to your model since then.
One way to do this is to checkout your first commit once you had django 1.8 working correctly locally then run
./manage.py makemigrations
then commit that
then go forward to your latest commit then run
./manage.py makemigrations
Now you should have 2+ migrations in each app that you have modified since upgrading to django 1.8.
Then you can fake initial on those apps that have 2+ new migrations for django 1.8
./manage.py migrate --fake-initial app1 app2
and the rest just
./manage.py migrate app3 app4
Now run your tests to confirm everything is working locally.
If you have changed migrations you will again want to test locally against a blank database to test that they work smoothly
Once that is working, record the 'migrate' commands that you used - then deploy your app to production and run just those migration commands once you have upgraded to django 1.8 on your server.
After Successful Completion
Take new dumps of your local and production databases
Uninstall South (assuming you had it installed before) from local and production environments
I'm sure there are a couple of holes in the above but hopefully that gives you the gist of what you need to do.
I am running python manage.py runserver or migrate and in both commands it is getting stuck on Performing system checks... Can you please help me out to understand what is the issue and how to solve it?
Admins-MacBook-Pro:driveu_backend gathole$ python manage.py runserver
/Users/gathole/.virtualenvs/du/lib/python2.7/site-packages/social_auth/models.py:4: RemovedInDjango19Warning: django.utils.importlib will be removed in Django 1.9.
from django.utils.importlib import import_module
/Users/gathole/.virtualenvs/du/lib/python2.7/site-packages/social_auth/utils.py:14: RemovedInDjango19Warning: The utilities in django.db.models.loading are deprecated in favor of the new application loading system.
from django.db.models.loading import get_model
/Users/gathole/.virtualenvs/du/lib/python2.7/site-packages/social_auth/models.py:4: RemovedInDjango19Warning: django.utils.importlib will be removed in Django 1.9.
from django.utils.importlib import import_module
/Users/gathole/.virtualenvs/du/lib/python2.7/site-packages/social_auth/utils.py:14: RemovedInDjango19Warning: The utilities in django.db.models.loading are deprecated in favor of the new application loading system.
from django.db.models.loading import get_model
Performing system checks...
just try
pip install -U Django
in your virtual environment.
I solve this by upgrade my Django version, without uninstall my MySQL 5.7 Server.
MySQL latest version was causing the issue... Just reverted MySQL version to 5.6 and it worked :)
This is probably a network problem. My code worked fine before but one day I add client = BertClient() in some files and I forgot to start the bert server (bert is an ML model). As a results, I encountered the same problem of starting my Django app.
You can check start from the app's urls.py file by commenting/uncommenting imports.
MySQL 5.7.x on Mac 14.4.0 have the same issue.
1.remove the mysql
2.brew install homebrew/versions/mysql56 (install an older version)
I am trying to learn about python-django web framework.
I have successfully installed database migration tool 'south' in my ubuntu os and also added it to INSTALLED_APPS for using this tool for my web app.
When I run any command using manage.py like
$ ./manage.py runserver
I get this error:
"/usr/local/lib/python2.7/dist-packages/South-1.0.2-py2.7.egg/south/db/generic.py:9: RemovedInDjango19Warning: The django.db.backends.util module has been renamed. Use django.db.backends.utils instead.
from django.db.backends.util import truncate_name
There is no South database module 'south.db.sqlite3' for your database. Please either choose a supported database, check for SOUTH_DATABASE_ADAPTER[S] settings, or remove South from INSTALLED_APPS."
I don't understand what it means. How can I fix this error?
Please give your useful suggestion to solve this error.Thanks
Firstly, you appear to be using the development version of Django. Don't do that, especially as you're just beginning. Use the latest actual release, 1.8.
Secondly, since 1.7 Django has included built-in migrations. There is no need to install South.
After installing of Django I get this error message (when I want to run migrations or runserver):
There is no South database module 'south.db.mysql' for your database.
Please either choose a supported database, check for
SOUTH_DATABASE_ADAPTER[S] settings, or remove South from
INSTALLED_APPS.
I dont want to use South and it is also not defined in INSTALLED_APPS . Why am I getting this error?
I got the same error. It is resolved by removing south from your environment , by running
pip uninstall south
Turns out South got installed after all because of some dependency,
and seems to be incompatible with current Django (1.82)
Solution that worked for me was to downgrade Django:
$ pip install -U "Django==1.7"
(ps. I didn't need to define anything about South in settings, so it is not used, but probably some installed app is looking for it anyway..)
I recreated this issue by doing these steps:
Installed django1.5 and south.
With the environment, Created a django project.
Upgrade django1.5 to django1.82
Now in runserver,
I've There is no South database module 'south.db.mysql' for your database. Please either choose a supported database, check for SOUTH_DATABASE_ADAPTER[S] settings, or remove South from INSTALLED_APPS.
Possible solution:
Uninstall south if you are in django1.82
Downgrade your django, where south is a different package.
I am using django-review package with one of my application where i am using the custom user model for Authentication. I have installed the django-review in my virtual environment and added the review app in my Installed_APPS as it is described in the documents of package.
but when i am running ./manage.py migrate review i am getting an error that django.db.utils.ProgrammingError: relation "review_review" does not exist
i did everythin same as it is defined in django-review package documents.
I am using django Version 1.6.5
You don't seem to have run ./manage.py migrate (or ./manage.py syncdb on earlier Django versions).