relation "django_session" does not exist - django, heroku - django

I deployed my app on Heroku, I can see it perfectly from the local server where the website works. The problem is that whenever I try to enter as the admin within the Heroku website (https://awayfromspain.herokuapp.com/admin/) I got the following error:
ProgrammingError at /admin/
relation "django_session" does not exist
LINE 1: ...ession_data", "django_session"."expire_date" FROM "django_se...
I also get this when I try to enter in the pages that are related to my models:
column myapp_experience.slug does not exist
LINE 1: ...p_experience"."title", "myapp_experience"."text", "myapp_exp...
I think I have problems with the database... but I tried to flush and I get:
Running python manage.py flush on ⬢ awayfromspain... up, run.2445 (Free)
You have requested a flush of the database.
This will IRREVERSIBLY DESTROY all data currently in the 'df1neimk7ipkd5' database,
and return each table to an empty state.
Are you sure you want to do this?
Type 'yes' to continue, or 'no' to cancel: yes
CommandError: Database df1neimk7ipkd5 couldn't be flushed. Possible reasons:
* The database isn't running or isn't configured correctly.
* At least one of the expected database tables doesn't exist.
* The SQL was invalid.
Hint: Look at the output of 'django-admin sqlflush'. That's the SQL this command wasn't able to run.
The full error: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "myapp_franceexperience" references "auth_user".
HINT: Truncate table "myapp_franceexperience" at the same time, or use TRUNCATE ... CASCADE.
Where franceexperience was a model that I deleted. How should I proceed? I applied migrations.
Thanks in advance !

Your migrations have obviously got out of sync; franceexperience should have been deleted when you removed the model.
You should makemigrations again locally and check that it adds a migration to delete that table. Then commit your code, push it, and do heroku run ./manage.py migrate; this should remove the deleted table but also hopefully add the missing session table.

Related

Django migrations integrity error column contains null values

django.db.utils.IntegrityError: column "required_tem_grid" contains null values
So I mistakenly gave wrong type of value when Django asked me to provide default value for existing rows. Problem is now that I am stuck with this error. I have been burned by this error before too and the only way I could recover was to create another db and running migrations again. Is there any other way? I have tried to revert to previous migration (initial) but this error pops up everywhere. There is no such column in the database that I can see. Is there some place this default value gets cached?
Well I managed to solve it this way: Delete migration files and cached files, remove offending entry from models, delete migration data from django_migrations table for the app, run makemigrations and migrate --fake-initial. I was then able to change models and run migrations.

Column Already Exist Error on Django Rest Framework on Heroku Migration

I have updated my model, but I couldn't do the migrations, the problem is:
I am getting an error like: column "blah blah" of relation "blah blah blah" already exists
The mentioned column should exist in DB, but it shouldn't exist on migration file because I did not do any addition or modification about that model field and it was already successfully created in one of the previous migrations, even used frequently without any error.
When I do the migration with --fake, this time it doesn't create the really unexisting field of migration file which is defined with that model update.
Deployed on Heroku, it may be caused by rollbacks of code layer, since after rollbacks code gets to older versions but DB stays same.
What is the best way without losing any data from production DB?
Following is a screenshot of the bash; timezone, endtime and start time fields already exist on model and DB before this migration, created on one of the previous successful migrations
Click here to screenshot of Heroku Bash when I try to run migrations
Thanks
You should not be running makemigrations on Heroku. Do it locally, then commit the result, deploy, and then run migrate only.
As it is, you've got completely out of sync; if you don't have any data you need to keep, the easiest thing to do is to delete your db and start again.

Django migrate getting OperationalError

I'm fairly new to Django, I am using 1.10 version. I reached a point where I was unable to migrate because of an error, and so backed up to an earlier migration using ./manage.py migrate myapp 0003_auto_20160426_2022 and deleted the later migration files. I then repaired my models.py and ran makemigrations, which worked fine. But when I attempted to migrate, I received the following error (only showing last few lines)
File
"/Users/wahhab/Sites/rts/env/lib/python3.5/site-packages/MySQLdb/connections.py",
line 280, in query
_mysql.connection.query(self, query) django.db.utils.OperationalError: (1022, "Can't write; duplicate key in table '#sql-72_4a6'")
I don't know how to move forward from this point so that I can continue working on my project. I have data in other apps but only a little test data in this new app so far, so I have considered deleting all migrations and the MySQL tables for this app and starting over, but I don't want to create a worse mess than I have and don't know what is causing this error. Any advice is welcome. Thanks!
Okay so a hackish solution has already been suggested by #raratiru.
Now the explanation for WHY you were facing the above problem is that when you deleted you migrations, Django resets all its counters, which also includes the counter of the key, but because the deletion of migrations was a manual one, the data still persists in your DB.
So there already exists objects in your DB with key = 1, 2, 3 ....and so on. But Django doesn't know this and hence when you have deleted just the migrations and not the data, Django faces a clash of key as Django again starts assigning automatic key values from 1, which already exists in the DB. But as the key needs to be unique, it gives you an error.
Hence if you delete both the migrations and the data, you don't get thee error.

IntegrityError: (1062, "Duplicate entry '3-add_author' for key 2")

Database is MySQL.
I use the django.contrib.auth.
Here is all the info:
manage.py dumpdata auth > my_auth.json --natural --exclude contenttypes
Then I deleted the entire database (drop database my_database), and created a new database (create database new_database)(use ./manage.py syncdb to create all tables).
Then
manage.py loaddata my_auth.json
I Got an error:
IntegrityError: (1062, "Duplicate entry '3-add_author' for key 2")
What's the problem?
Any help will be greatly appreciated. Thank you!
(Updated)
You're right (re your comments below). The problem is indeed with auth.permission.
When you run syncdb, auth.permission is populated automatically with default values for all installed models. Any subsequent runs of syncdb will add new entries for any models that were recently added.
If at a later stage you reset the database and run syncdb again, the values will be repopulated and depending on the order in which installed models are inspected, the associated permissions may be added in a different order giving it different ids from your previous database (if models were installed in stages).
To avoid this problem, you can either leave auth.permission out when dumping your auth data (as you've already pointed out in your comments), or resetting the auth.permission table before loading your data dump.
Also, it is important to use natural keys (--natural) when dumping out your data so that it does not reference related data using its integer id (which may not be the same when loaded in another db). This feature was introduced in Django 1.2.

Django: flush command doesnt completely clear database, reset fails

I rewrote a lot of my models, and since I am just running a test server, I do ./manage.py reset myapp to reset the db tables and everything has been working fine.
But I tried to do it this time, and I get an error,
"The full error: contraint owner_id_refs_id_9036cedd" of relation "myapp_tagger" does not exist"
So I figured I would just nuke the whole site and start fresh. So i did ./manage.py flush then did a syncdb this did not raise an error and deleted all my data, however it did not update the database since when I try to access any of my_app's objects, i get a column not found error. I thought that flush was supposed to drop all tables. The syncdb said that no fixtures were added.
I assume the error is related to the fact that I changed the tagger model to having a foreignkey with a name owner tied to another object.
I have tried adding related_name to the foreignkey arguments and nothing seems to be working.
I thought that flush was supposed to drop all tables.
No. According to the documentation, manage.py flush doesn't drop the tables. Instead it does the following:
Returns the database to the state it was in immediately after syncdb was executed. This means that all data will be removed from the database, any post-synchronization handlers will be re-executed, and the initial_data fixture will be re-installed.
As stated in chapter 10 of The Django Book in the "Making Changes to a Database Schema" section,
syncdb merely creates tables that don't yet exist in your database — it does not sync changes in models or perform deletions of models. If you add or change a model's field, or if you delete a model, you’ll need to make the change in your database manually.
Therefore, to solve your problem you will need to either:
Delete the database and reissue manage.py syncdb. This is the process that I use when I'm still developing the database schema. I use an initial_data fixture to install some test data, which also needs to be updated when the database schema changes.
Manually issue the SQL commands to modify your database schema.
Use South.