I built a Django 1.9 project locally with sqlite3 as my default database. I have an application named Download which defines the DownloadedSongs table in models.py:
models.py
from __future__ import unicode_literals
from django.db import models
class DownloadedSongs(models.Model):
song_name = models.CharField(max_length = 255)
song_artist = models.CharField(max_length = 255)
def __str__(self):
return self.song_name + ' - ' + self.song_artist
Now, in order to deploy my local project to Heroku, I added the following lines at the bottom of my settings.py file:
import dj_database_url
DATABASES['default'] = dj_database_url.config()
My application has a form with a couple of text fields, and on submitting that form, the data gets inserted into the DownloadedSongs table. Now, when I deployed my project on Heroku and tried submitting this form, I got the following error:
Exception Type: ProgrammingError at /download/
Exception Value: relation "Download_downloadedsongs" does not exist
LINE 1: INSERT INTO "Download_downloadedsongs" ("song_name", "song_a...
This is how my requirements.txt file looks like:
beautifulsoup4==4.4.1
cssselect==0.9.1
dj-database-url==0.4.1
dj-static==0.0.6
Django==1.9
django-toolbelt==0.0.1
gunicorn==19.6.0
lxml==3.6.0
psycopg2==2.6.1
requests==2.10.0
static3==0.7.0
Also, I did try to run the following commands as well:
heroku run python manage.py makemigrations
heroku run python manage.py migrate
However, the issue still persists. What seems to be wrong here?
Make sure your local migration folder and content is under git version control.
If not, add, commit & push them as follows (assuming you have a migrations folder under <myapp>, and your git remote is called 'heroku'):
git add <myapp>/migrations/*
git commit -m "Fix Heroku deployment"
git push heroku
Wait until the push is successful and you get the local prompt back.
Then log in to heroku and there execute migrate.
To do this in one execution environment, do not launch these as individual heroku commands, but launch a bash shell and execute both commands in there: (do not type the '~$', this represents the Heroku prompt)
heroku run bash
~$ ./manage.py migrate
~$ exit
You must not run makemigrations via heroku run. You must run it locally, and commit the result to git. Then you can deploy that code and run those generated migrations via heroku run python manage.py migrate.
The reason is that heroku run spins up a new dyno each time, with a new filesystem, so any migrations generated in the first command are lost by the time the second command runs. But in any case, migrations are part of your code, and must be in version control.
As Heroku's dynos don't have a filesystem that persists across deploys, a file-based database like SQLite3 isn't going to be suitable. It's a great DB for development/quick prototypes, though. https://stackoverflow.com/a/31395988/784648
So between deploys your entire SQLite database is going to be wiped, you should move onto a dedicated database when you deploy to heroku I think. I know heroku has a free tier for postgres databases which I'd recommend if you just want to test deployment to heroku.
python manage.py makemigrations
python manage.py migrate
python manage.py migrate --run-syncdb
this worked for me.
I know this is old, but I had this issue and found this thread useful.
To sum up, the error can also appear when executing the migrations (which is supposed to create the needed relations in the DB), because recent versions of Django check your urls.py before doing the migrations. In my case - and in many others' it seems, loading urls.py meant loading the views, and some views were class-based and had an attribute defined through get_object_or_404:
class CustomView(ParentCustomView):
phase = get_object_or_404(Phase, code='C')
This is what was evaluated before the migrations actually ran, and caused the error. I fixed it by turning my view's attribute as a property:
class CustomView(ParentCustomView):
#property
def phase(self):
return get_object_or_404(Phase, code='C')
You'll know quite easily if this is the problem you are encountering, as the Traceback will point you towards the problematic view.
Also this problem might not appear in development because you have migrated before creating the view.
Related
Added a small model 'new_model' in existing app 'existing_app' on Django,
Entered commands manage.py makemigrations and manage.py migrate. It migrated perfectly the changes to local database.
Tried to apply same on heroku but its not working there. I then tried to setup heroku database in local settings.py of project and migrations worked, but it shown some well known error. I have attached the output with this discusssion. Attaching the final screenshot the final screenshot as output.
Just In Case if it may help_________
The following are the methods I have applied before the final solution:-
With heroku run manage.py makemigrations
Adding makemigrations command to procfile
Pushing migrations as well, so it may replace server migrations
Heroku bash and tried "makemigration" and "migrate" on it
Alternate solution result Alternate solution result
The all four mentioned steps provided this output:- "No migrations to apply, and on migrate it shows you dont have new migrations",
helping out to migrate changes on database.
Thank You.
My django app is containerized along side postgresql. The problem is that migrations do not seem to be persisting in the directory. Whenever I run docker exec -it <container_id> python manage.py makemigrations forum, the same migrations are detected. If I spin down the stack and spin it back up the and run makemigrations again, I see the same migrations detected. Changes to the fields, adding models, deleting models, none ever get detected. These migrations that do appear seem to be getting written to the database, as when I try to migrate, I get an error that there are existing fields already. But if I look at my migrations folder, only the init.py folder is present. All the migrate commands add no changes to the migrations folder.
I also tried unregistered the post model from the admin and spinning up the stack, yet I still see it present in the admin. Same things with changes to the templates. No change I make sticks from inside docker seems to stick.
*Note this problem started after I switched to wsl 2 and enabled it in docker desktop (windows)
**Update migrations can be made from bash of docker container
I found out what the problem was. My docker-stack.yml file was pointed to a directory that did not exist in the dockerfile.
We are fairly new to Django. We we have an app and a model. We'd like to add an 'Category' object to our model. We did that, and then ran 'python manage.py makemigrations'.
We then deploy our code to a server running the older code, and run 'python manage.py migrate'. This throws 2 pages of exceptions, finishing with 'django.db.utils.ProgrammingError: (1146, "Table 'reporting.contact_category' doesn't exist")'
This seems to be looking at our models.py. If we comment out Category from our model, and all references to it, the migration succeeds.
I thought that the point of migrations is to make the database match what the model expects, but this seems to require that the model match the database before the migration.
We clearly are doing something wrong, but what?
I believe you skipped some migration in the server, so now you are missing some tables (I have been in that situation. Ensure migrations directories are on your .gitignore. You CAN NOT check in migrations files, you have to run makemigrations on the server). This can be solved by tracing back up to the point the database and models files match, but it is a risky process if it is your production database, so you should make a full backup before proceeding, and try the process on a different computer before.
This would be my advice:
Delete migration files from the server.
Comment the models that rise the error.
Set the server's migration history to the point the
database is, using python manage.py makemigrations and python manage.py migrate --fake-initial (this will update the migration files without actually attempting to modify the database).
Uncomment the models that raise the error.
Run python manage.py makemigrations and python manage.py migrate.
If, after you comment the models that raise the exception, you get a different exception, you have to keep on commenting and attempting again. Once a migrations succeeds, you can uncomment all commented models and make an actual migration.
Remember to run python manage.py makemigrations if you made changes to the models.py then run python manage.py makemigrations
Both commands must be run on the same server with the same database
I've just upgraded my project to Django 1.8.4. I've never used migrations in this project before. I discovered that I had to explicitly run the "makemigrations" command against four of my apps since they contained foreign keys to the auth_user table. Do I need to run the makemigrations command against my other six applications? The reason I ask is because the documents say,
If your app already has models and database tables, and doesn’t have migrations yet (for example, you created it against a previous Django version), you’ll need to convert it to use migrations"
However, when I ran the command against my "home" app, I received this message:
No changes detected in app 'home'
When converting a project to Django 1.8, should you run the makemigrations command against all of your apps and then run "migrate --fake-initial" if the actual database tables already exist?
Thanks.
Update: Make sure that the migrations folder contains an __init__.py.
Indeed, there are many times, I have to delete and recreate my development database.
During this procedure, I have encountered the same issue especially after upgrading to Django 1.8.* / 1.9.*.
In my script, after deleting the contents of my migrations folders, I am running makemigrations in all my applications separately simultaneously.
./manage.py makemigrations <myapp1> <myapp2> ... <myappN>
Before that, I backup all my data:
./manage.py dumpdata --exclude auth.permission --exclude contenttypes --exclude admin.LogEntry --indent 2 > db.json
I started a new Django 1.8 project and realized that I missed something (i had done the initial migrations). I dropped the database (postgreSQL) and deleted migration folders from all my apps in order to start from scratch.
Now, when I 'syncdb' I get this error:
django.db.utils.ProgrammingError: relation "auth_group" does not exist
and when I makemigrations I get this:
No changes detected
What am I doing wrong?
Probably you should try to create migrations modules (folders named migrations with empty file named __init__.py inside of each directory) for your apps. And then run manage.py makemigrations again.
The problem is on no changes detected. Please execute these commands with your app name. I guess you didn't add it (just like the mistake I did):
python manage.py makemigrations myappname
python manage.py migrate myappname
The above error occurs when you have django.contrib.admin among the installed applications.
Run these commands in their respective order.
**
./manage.py makemigrations
./manage.py migrate auth
./manage.py migrate**
That worked for me perfectly.
Doing ./manage.py migrate auth first didn't work for me, and every ./manage.py command was throwing this error. My problem was that I was doing stuff with the Group manager in module scope.
If you have code like this in module scope:
customers_group = Group.objects.get(name='customers')
Move it inside a function that is called at runtime instead.
def xyz():
...
customers_group = Group.objects.get(name='customers')
I had the similar problem with Django2.2 migrations. I will post what helped in case someone is looking to fix this.
I commented out all urls to apps(like my_app.urls, your_app.urls) in main project urls.py and then ran makemigrations, it worked.
I think this error is due to some forms/views referring to model/fields that are not yet created. It seems django traverses urls.py to before making migrations
It can be either:
one of the pip dependencies from requirements.txt was using South
had this error when running tests which do migration in Django 1.8. Found the lib with issue by running tests in verbose mode. Consider upgrading the library to newer version.
manage.py test -v 3
one of the /migrations folder might still has old South migrations files.
It can be because others are still adding migrations when you are trying to upgrade Django. Use the following to make sure that the expected migrations files are present in each app.
manage.py showmigrations
One of your paths ("pointing urls.py on your core folder along with the settings.py") makes that problem occur importing django.contrib.auth and directly using methods and properties of "auth" after calling those views
Remove all migrations except "init.py" of each apps
Go to projects urls.py and comment out all the paths
run "heroku run python manage.py makemigrations"
run "heroku run python manage.py migrate"