I have a Django 1.11 project and I'm trying to squash all migrations by deleting and re-making all of them.
However, when I go to run manage.py makemigrations I get an error like:
ValueError: The field app1.Model1.campaign was declared with a lazy reference to 'app2.Campaign', but app 'app2' isn't installed.
However, app2 is definitely installed. I even print out my INSTALLED_APPS list in my settings.py to confirm it is. What's causing this error?
Related
I know there are many questions about this problem, I looked through the solutions and unfortunately none of them worked for me.
I created a new app called "usermanagement", and added a model to the app. After adding the model I added usermanagement to INSTALLED_APPS in settings. Then I ran python manage.py makemigrations, and python manage.py migrate. This all worked fine! I also did try running the migrations with the app-name.
The problems start when I try to add a new instance of the model to the database in the Python-Django shell, by using:
>>>a = ClubOfficial(name="randomName", email="randomemail#random.com")
>>>a.save()
I get the following error:
django.db.utils.ProgrammingError: relation
"usermanagement_clubofficial" does not exist
LINE 1: INSERT INTO "usermanagement_clubofficial" ("name", "email") ...
Below is the model code:
class ClubOfficial(models.Model):
name = models.CharField(max_length=254)
email = models.EmailField(max_length=254)
If it helps, I use postgresql, and have tried restarting the server. The other apps in the program also work perfectly fine, it is just usermanagemenet that has this problem.
Does anyone know what could be going wrong?
Thank you for your time!
Note: I created a new app now with a different name, copy-pasted things from usermanagement and everything worked fine. I think the problem might be that before there was an app named usermanagement which was deleted, before I created it again. Maybe that messed up the database somehow.
TL;DR: Make sure your app's migrations folder has an __init__.py file. If it isn't there, create it again as an empty file.
I ran into this. In my case I had a previously working django app, not yet moved to production, so I deleted everything in my app's migrations folder, then using django extensions I wiped the postgresql database and cached files with:
./manage.py clear_cache
./manage.py clean_pyc
./manage.py reset_schema
./manage.py reset_db
# then deleted all files (including __init__.py) from my app's migrations folder.
I verified that my postgresql database had no tables. I then ran:
./manage.py makemigrations
./manage.py migrate
Which gave the output:
No changes detected
./manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
(about 11 more lines of output here which are similar)
It is notable that my model's names where nowhere in the migration. I printed the tables in my postgresql database and the Widget and Section tables were both missing. Running the app gave me this error (I substituted 'app' and 'model' for their real names):
ProgrammingError at /my_path
relation "app_model" does not exist
LINE 1: ..."."my_field", "app_model"."my_field" FROM "appname...
So the tables for the models were not being created in the database. My app's migrations folder was also completely empty. The solution was to just add an empty __init__.py to my app's migrations folder, and after that running makemigrations was able to create and save the migration file in the folder. This could then be executed with migrate. You can test this for yourself by running makemigrations with and without the __init__.py in the migrations/ folder.
This solution was not mine but one given by user Ljubitel on another post but it was not the accepted answer there, but the accepted answer didn't work for me so I wrote this solution here to hopefully help others.
I had this same problem, but all I had to do was run
$ python manage.py makemigrations
and
$ python manage.py migrate
In case you have deleted your migration folder.
Create a folder called migration in whatever app name you have created and then create a file in the migration folder called __init__.py
In my case I was pointing to a different databases between my local server and the production server. The database that the production server was pointing to was a few versions behind, so the server could not locate the relation. If your issue were localized to one environment, check the configs first.
Another method to fix relation does not exist error
Create same table in db(postgre, mysql) using sql query tool
now comment your model in models.py and admin.py
run migration using :
python manage.py makemigrations app_name
python manage.py migrate
now uncomment and run migrations command again
I encountered same issue and fixed using following method, I am using postgres(pgadmin 4).
I have 2 related questions.
I have deleted all my migrations, including the migrations directory, from all the apps in my project. I've started with a clean database. But still, when I run ./manage.py makemigrations, django says there are no changes to be made. How do I completely start over with migrations? No squashing, just starting over.
It seems that when I call makemigrations, django consults the database. I'd like my codebase to be the only source of truth for my migrations. Is there a way to do this?
If an app doesn't have a migrations/ directory with an __init__.py file (even on Python 3), Django won't create any migrations if you don't specify the app name. You either have to create the directories and __init__.py files, or you have to call ./manage.py makemigrations <app_name> for each app, which forces Django to create the directory.
It doesn't. It may connect to the database during the makemigrations command, but the migrations are purely based on your models.
I'm upgrading a django project from 1.6.11 to 1.7.9. I use DRF 2.4.4. Once everything is working fine, I'll upgrade to DRF 3.x
I started using django-oauth2-provider, but it can not work with django 1.7, so I'm moving to django-oauth-toolkit.
for the record, it does not work because HttpResponse does not accept mimetype anymore. it has to be 'content_type'. PRs for django-oauth2-provider are abandoned.
I pip installed it and added the oauth app to INSTALLED_APPS. Their docs suggest using syncdb and then migrate, although Django 1.7 deprecated syncdb. I tried to migrate it with ./manage migrate oauth2_provider unsuccessfully. It keeps reporting:
ValueError: Dependency on unknown app: provider
provider happens to be the old module for oauth, that was coupled with 2 of my apps.
I removed it from INSTALLED_APPS, commented all imports and usages of its classes, changed the model that had a FK to provider.oauth2.models.Client (I removed that field), and tried again. I got the same error.
The initial migration of one of the apps seems to be the only valid code that uses provider :
class Migration(migrations.Migration):
dependencies = [
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
('contenttypes', '0001_initial'),
('provider', '__first__'),
]
however, after this migration I removed that field. With South I'd probably do ./manage.py schemamigration myapp --auto and then migrate.
However, when I try to makemigrations myapp I get the same error.
I'm totally lost. How can I get rid off the old oauth module and get the new one? Do I have to run makemigrations for oauth2_provider or just migrate? My guess is that only migrate. Why can't I make a migration with the changes in myapp model?
This has happened to me. Try manually removing the "provider" app line in initial migration that refers to it. Alternately, you can delete all migrations and run "makemigrations" from scratch (remember, for initial migrations you have to do it once for every individual app).
I have a Django application initially created for version 1.6 and I've just finished the upgrade for the last version. All the models has managed = False and prior none of them was managed by south and now I want to start using Django migrations for 1.7 version.
Which would be the best and seamless way to do it? I'm afraid that just changing managed = True in all models and run manage.py makemigrations will make a mess in both migrations files and database.
Thanks
EDIT
As was suggested I ran manage.py makemigrations. It created the script 0001_initial with some model definitions but not for all the objects in models package. It creates 11 tables but I have 19 tables. All models has managed = True and I don't have any database router.
Most depends by the code
The project does not have migrations at all
./manage.py makemigrations
./manage.py migrate
The project has South migrations:
you can:
move the south migrations in south_migrations
or
totally remove the south migrations
and
./manage.py makemigrations
./manage.py migrate
if you go for option 1 you have to remember to keep uptodate your migrations with both systems (south and django). This is useful only if you want to keep django <1.7 compatibility
You have a pluggable application
This is the most complex situataion as you must preserve the south compatibility and you have to manage different version of south. Here the how to:
move the south migrations in south_migrations
run ./manage.py makemigrations
to prevent South to load the wrong migratins put the following code into migration.__init__.py
```
"""
Django migrations
This package does not contain South migrations. South migrations can be found
in the ``south_migrations`` package.
"""
SOUTH_ERROR_MESSAGE = """\n
For South support, customize the SOUTH_MIGRATION_MODULES setting like so:
SOUTH_MIGRATION_MODULES = {
'wfp_auth': 'wfp_auth.south_migrations',
}
"""
# Ensure the user is not using Django 1.6 or below with South
try:
from django.db import migrations # noqa
except ImportError:
from django.core.exceptions import ImproperlyConfigured
raise ImproperlyConfigured(SOUTH_ERROR_MESSAGE)
```
I have done the migration from 1.6 to 1.7 on an existing project. It was fairly painless.
I renamed my old South migrations folders and let the django 1.7 migrations create a new one. (i.e. $mv appname/migrations appname/migrations.south) That will make it easier to go back to South for any reason and will keep from having a jumbled mess of both in your migrations folders.
I'm trying to get South to work - it worked fine on my PC, but I'm struggling to deploy it on my webhost.
Right now it seems that any changes I make to add/remove items from INSTALLED_APPS aren't being picked up by syncdb or diffsettings. I've added south to my list of INSTALLED_APPS, but the tables it needs aren't being created when I run syncdb. If I change other settings, they are picked up, it just seems to be INSTALLED_APPS that doesn't work.
If I run
from south.db import db
from the shell I get with manage.py shell, I don't get any import errors, so I don't think it's a problem with where south is. I've tried removing all my other applications (other than the Django standard ones), and tables for them still get created when I run syncdb.
Even if I delete INSTALLED_APPS completely, I still get the old list of INSTALLED_APPS when I run manage.py diffsettings.
Any ideas what I've done wrong?
Thanks,
Dom
If you write a migration for an application, syncdb wont work.
You have to use
manage.py migrate
syncdb wont work for applications which are hooked under migration using south. Those applications model change will be noticed only depending on south migration history.
South Migration Docs
The answer, it turns out, is that I'm a moron. I'd done this:
In settings.py:
...
INSTALLED_APPS = (
...
)
...
from localsettings import *
In localsettings.py
...
INSTALLED_APPS = (
...
)
...
I'd created localsettings.py from settings.py, to contain things only relevant to the current location of the project (like database settings), and forgot to delete the INSTALLED_APPS section.
Apologies for doing such a flagrantly stupid thing.