I am building an app called 'competencies'. I made changes to models, migrated the app locally, and everything worked. This is my eighth migration on the app.
I have deployed the app on heroku, so I committed changes and pushed to heroku. I can see that the changes went through, because the new migrations appear in the heroku files. When I log in to heroku and try to migrate the competencies app, I get the following error:
NoMigrations: Application '<module 'django.contrib.admin' from '/app/.heroku/python/lib/python2.7/site-packages/django/contrib/admin/__init__.py'>' has no migrations.
I have searched for this error, and I have not found anything meaningful. Can anyone suggest what I am doing wrong, or how to address the issue?
django.contrib.admin should not have migrations. Contrib packages are not south managed.
If you EVER ran python manage.py schemamigration django.contrib.auth --XXX on your local it would create the migrations folder in your local copy's install of the venv's django. However, this will never get transferred to heroku.
test something for me. create a new copy of your site on your local machine
new DB
new virtualenv
new folder w/ new clone of repo
try to run python manage.py migrate if you get the same error its b/c you broke your virtualenv with south.
Something else you could try IF your database models have not changed a bunch since the last working copy:
roll your models back to the last working configuration
delete EVERY app's migrations folder
truncate south_migrations table
run python manage.py schemamigration --initial X for each of your apps.
push and migrate --fake
redo your model changes
create migrations for the model changes
push and migrate regularly
I recently encountered this error after dumping a live database to a dev box for testing data migrations.
One of the dependencies was throwing this error (specifically taggit). I think that I have a different version of taggit on the dev box which does not have migrations, but the database I dumped had two migrations for taggit in south_migrationhistory.
I deleted the entries in south_migrationhistory for the problem app erroneously claiming NoMigrations and that solved my problem. Everything's running again.
Apart from many answers posted above, south.exceptions.NoMigrations is often exception after 2014 (Django 1.7) because of changed migrations directory. The directory is default for Django built in migrations.
For south migration, the directory is south_migrations. South>=1.0 can recognize this and automatically detect migrations. See details here on Django docs
In this case, update South:
pip install -U South
Or you can also specify migration directory on settings file (for every app installed).
I found an odd edge case, involving Kombu.
I'm maintaining a legacy Django 1.5 project on Ubuntu 14.04, and I previously had this setting to get Kombu to play nicely:
SOUTH_MIGRATION_MODULES = {
'kombu_transport_django': 'kombu.transport.django.south_migrations',
}
However, after I upgraded to Ubuntu 16, there were some minor tweaks in the Python stdlib that again broke Kombu. Upgrading Kombu was the only immediate solution, but that gave me another Kombu error similar to what OP found:
NoMigrations: Application '<module 'kombu.transport.django' from '/myproject/.env/local/lib/python2.7/site-packages/kombu/transport/django/__init__.pyc'>' has no migrations.
This error message is nearly worthless, but I eventually realized the problem was my SOUTH_MIGRATION_MODULES setting. It turns out, the old kombu.transport.django.south_migrations was removed, and South trying to import this missing migration directory is what was causing the error. The fix was to remove that line.
Try pip install --upgrade django
The NoMigrations error often shows up if you downgrade your Django version.
In my case, I had installed a package which automatically uninstalled my current Django version and installed a downgraded it.
Installing the updated version was a quick fix.
Also, you may want to check in your INSTALLED_APPS if you have included all of your apps including the 'django.contrib.auth' and 'django.contrib.admin'
Related
I have a Django project that uses old version of django.db.models.signals - post_syncdb. I changed models and added new to the db. To make docker-compose up and launch Django with docker I need to make a migration, but when I'm doing this it shows me this error
`AttributeError: module 'django.db.models.signals' has no attribute 'post_syncdb'
I tried google the solution and noticed three ways:
Check the Django version used in the project, as the post_syncdb signal has been deprecated since Django 1.9.
Look through the project's code and identify any references to post_syncdb signal. If there are any, you may have to update the code to use a different signal.
If the error persists, it may be a bug in one of the installed packages. You can try to update the packages to the latest version or raise an issue on the package's repository.
The problem is that it's not mu project and I currently work on dev branch. How do I fix it and make a migration?
I am having issues migrating my Django app database on Heroku.
I deleted previous migrations (and they are ignored by git), and whenever I run python manage.py makemigrations, I have a previous dependency showing up in the newly created (001_initial.py).
Here is what I get in dependencies:
dependencies = [
('auth', '0013_auto_20190406_1745'),
]
So what happens is that Django does not find those old dependencies in Heroku (it still works fine locally).
I am looking for a way to reset migrations but couldn't find a solution looking into Django doc and online.
I tried deleting the migrations folder and running the command python manage.py myapp zero but was unsuccessful.
I started creating my website on my own PC using the Django-cms install script then I tried to add a lot of applications such as Django-Helpdesk and others and everything was smooth until I tried to add pieces of djangoSHOP demo project and dependencies to email_auth.
Then I started to have report that the migration history was inconsistent and migrations applied out of order.
Before adding djangoShop to the installed apps, I just add the following commands to setup the DB:
manage.py migrate --run-syncdb --noinput
manage.py migrate --noinput
and everything was ok.
Now, as I'm just starting, I don't have changes to the schema to apply but most of the django apps I try to install have migrations folders with several migrations.
I don't want to update an existing schema, I want to create a new one.
I'm working from a blank database so do I really need to apply all those migrations ? To me it seems that the default behaviour of running migrations is not compatible with starting from a blank db,
I don't understand what to do just initialise the database to just have the required tables created.
Did anyone got the same kind of problems?
How did you fixed it?
Edit:
django-cms>=3.5,<3.6
Django 1.11.19
Error message:
Django InconsistentMigrationHistory: Migration Helpdesk.000xxxxx.py is applied before its dependency email_auth.0001_initial.py on database 'default'
I recently built a dev machine to use at home, I've been spending the last couple nights trying to get it running with a development version of our website.
1] First off cloned the repo of our website into a local folder.
2] Then I created a virtualenv using virtualenvwrapper for the website
3] I then used the requirements.txt in the repo to install dependencies, this failed a ton of times and I ended up having to go through the requirements.txt one line at a time until I found out i needed mercurial installed for it to finish.
4] After verifying my dependencies were all installed I went to sync the db with "python manage.py syncdb" and got the error: "DatabaseError: no such table: django_site". This seems to create an empty db file in the location specified in the settings.py.
5] I read the other stack-overflow posts about this error and tried commenting both django.contrib.sites and django.contrib.sessions from my installed apps as that worked for some people, it has not for me. I also tried using python manage.py migrate as I have south in my installed apps and it was mentioned in another post but no luck for me.
I believe I am doing something fundamentally wrong in this process as I was able to do it just fine at work weeks ago and that dev machine still works fine.
I'm not the most adept individual when it comes to Linux and I may have some kind of path issue or what have you. Any help would be great!
Do this:
pip install south
Add south to INSTALLED_APPS.
And run ./manage.py syncdb
and ./manage.py migrate
I am using a 3rd party app inside my django application and the older versions of it had a dependancy on the django auth model, but the newer version supports the custom auth model of django 1.5.
The problem I am having is that when I install the app and migrate app, it breaks on the migration 002 because it is referencing a table that the final version of the app doesn't need, therefore i dont have.
If i turn off south and just do a syncdb everything works fine. But then I will have to do fake migrations for all my other apps. Is there an easy way that I can have either south skip these errors and keep proceeding with the migrations or south just use the models.py to create the schema and then for me to do a fake migration for just that one app?
Thanks for your help :)
I ended up doing this
SOUTH_MIGRATION_MODULES = { 'app_with_broken_migration':'ignore'}
then running syncdb
then removing the ignore migrations line and running
manage.py migrate app_with_broken_migration --fake
I usually make a temporary modification to the migration script that fails. Comment out or modify the parts that are not needed, run the migrations, then restore everything to the way it was before.
It's not ideal, and it involves some duplication of work - you have to do the same steps both on dev machine and on the server, but it lets you preserve South support and work around the failing migration.