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?
Related
I have an django application with version 2.2.13 and django oauth toolkit 1.0.0. In the effort to update to Django 3.0, I need to update the django-oauth-toolkit, but every version after version 1.0.0, I run into a migration problem because my application (oauth2) extends the abstract application (AbstractApplication) model from the oauth2_provider (from django-oauth-toolkit).
from oauth2_provider.models import AbstractApplication
class Application(AbstractApplication):
# there are more fields added here
pass
This custom oauth application (oauth2) has 28 migrations that were generate inside the project itself.
When we try to run all migrations from scratch (we do this on our CI Server), we get an error trying to run migration 0001 for the app oauth2_provider
ValueError: Related model 'oauth2.Application' cannot be resolved.
There is an issue similar to my problem open on the project, https://github.com/jazzband/django-oauth-toolkit/issues/778, but workaround provided does not work, and I have not found other solution to it.
Thanks.
when you swap the application model,
you should create and run the migration defining the swapped
application model prior to setting OAUTH2_PROVIDER_APPLICATION_MODEL.
It is possible to force your migration providing the custom model to run in the right order by adding:
run_before = [
('oauth2_provider', '0001_initial'),
]
to the migration class.
You can find more details here
Running Django 1.9 I'm trying to follow the install instructions for django-userena, to add it to an existing django project.
When I try to create the Accounts app:
python manage.py startapp accounts
I get this error:
userena.compat.SiteProfileNotAvailable
Other questions indicate that I need to set AUTH_PROFILE_MODULE, as directed in the installation instructions. However, these assume I already have an Accounts app created, within which I've created a Profile model.
So I seem like I'm stuck in a circular dependancy where I can't create the Accounts app without a Profile model, but I can't create the Profile model without the Accounts app!
Also, from the instructions, it doesn't appear the AUTH_PROFILE_MODULE should be required yet at this step, in order to create the Accounts app.
How do I solve this?
Make sure to that userena and the other apps are not yet installed, since
manage.py startapp accounts is the first step in the installation instructions.
I am going through django documentation. And here I have a situation. In one of the documentation, I am told to do
python manage.py migrate
And in the other
python manage.py syncdb
I can't do the first one(Error: no migrate command found.) but second works fine for me. Is this a version issue or I need to take care of something else.
The migrate command is new in the upcoming Django 1.7, which hasn't been released yet.
For earlier versions you can use syncdb, or the external app South.
When you're reading the documentation, use the Documentation version switcher to select the correct version.
For example, the current 1.6 Tutorial uses syncdb, but the dev tutorial (written for the upcoming 1.7) uses migrate.
The command migrate belongs to an application called south (http://south.aeracode.org/).
From the website:
This is South, intelligent schema and data migrations for ​Django projects.
Prior to Django==1.7 you had to install a third party application in order to perform database migrations.
Please see documentation at readthedocs
It depends what version of the documentation you are reading. migrate is the command from South which up until the latest (currently development, or dev) version of django was a separate app. It's finally getting integrated into Django (basically every django project uses it anyway as a matter of course, so it is well worth reading up on).
In the bottom right of the django documentation page there is a selector where you can switch between different versions of Django, so if you're looking for information for your project it is a good idea to change to the version of Django you're currently using.
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'
I keep getting this error every time i create a new django project using titanium (eclipse) with pydev.
Actually, it did create the file settings.py
I wonder what make this error and how to fix it?
It's really a PyDev issue with Django 1.4. A new release (2.5.0) will be done later this week properly supporting the layout changes in Django 1.4.
You can still use the project created this way, but you have to do some manual things:
Move the contents inside of the folder that was created to your module (this was the structural change done in django 1.4)
The settings.py won't have the details you entered in the wizard (i.e.: manually edit the settings.py)
In the project django's properties (right click project > properties and check the django properties page), you have to put the proper settings to the settings module and manage.py.
I updated my pydev today to the last version and now it seems to be working beautifully...