i purchased an outsource service to develop a web site in django to be deployed in heroku and AWS S3 (boto package).
Unfortunately the developer did not comment the code, despite it was asked, and left the project uncompleted for following up with a bigger client.
I've hired another django 'expert' to fix a part which was not developed, and he want to (over)charge for deployment testing, which i think should be a normal matter for good practices! i am working on my own budject, and need to work it out myself.
I was able to make the project run locally and make myself the frontend templates which were not fully developed, but I am having issues in deploying the code on my own staging environment.
I set up a staging environment under my credential to check if everything is ok, before pushing to production.
I think I almost get there, though:
heroku run python manage.py migrate --all --noinput --app my-app-staging
generate in the console:
Running `python manage.py migrate --all --noinput` attached to terminal... up, run.4833
DatabaseError: relation "south_migrationhistory" does not exist
LINE 1: ...gration", "south_migrationhistory"."applied" FROM "south_mig...
In the browser:
DatabaseError at /
relation "django_site" does not exist
LINE 1: ..."django_site"."domain", "django_site"."name" FROM "django_si...
^
Request Method: GET
Request URL: http://my-app-staging.herokuapp.com/
Django Version: 1.5.6
Exception Type: DatabaseError
Exception Value:
relation "django_site" does not exist
LINE 1: ..."django_site"."domain", "django_site"."name" FROM "django_si...
^
Exception Location: /app/.heroku/python/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py in execute, line 5
I checked my settings and they look ok:
i check AWS S3 bucket and it is able to write there;
settings in heroku console display that the db has been created.
I followed:
Heroku created table but when I'll migrate, he says that doesn't created
but it looks my locals.py are ok too, and in my local git branch .gitignore will exclude db.sqlite
My git and heroku ssh keys have been generated and added, so i dont' think it is an issue of authentification.
How could i check that the db is properly connected to django project and I am not invalidated?
Could you please help in debriefing to understand what this error means and how to solve it?
So much thank you.
It sounds like you might not have created the initial South migration tables on your staging server. This is actually done using syncdb:
Once South is added in, you’ll need to run ./manage.py syncdb to make the South migration-tracking tables (South doesn’t use migrations for its own models, for various reasons).
To run this on Heroku, you'll probably want to use something like
heroku run python manage.py syncdb
Once this is done, you should be able to move forward with the South commands.
Related
On our staging server we observed a runtime error stating a field is missing from a database,
column our_table.our_field does not exist
LINE 1: ...d"."type", "our_table"...
The field was added during a recent update with a complicated migration squashing process. It's possible that some errors were made during this process, but "manage.py showmigrations" command shows that the migration has been applied and "manage.py makemigrations" does not create any new migration. As we do not run tests on our staging or production databases, we are trying to figure out the most effective method for identifying such errors.
In short, how can we identify mismatches between the database and Django models caused by an incorrect migration like the following?
python manage.py migrate our_app --fake
I suppose I am looking for something like
python manage.py check_database
Edit: Many thanks for the suggestions. However, this is more of a deployment than a development question because the problem likely occurred when our devops tried to apply the squashed migrations while retaining data on the staging server (which will be case on production). It was scary to learn that such inconsistency can occur when makemigrations and showmigrations do not show any problem and can therefore also happen on production.
The bottom line is that we need some way to ensure our database matches our models after deployment.
I have a django REST project and a PostgreSQL database deployed to DigitalOcean. When I develop locally, I have a separate dockerized REST server and a separate PostgreSQL database to test backend features without touching production data.
My question arises when I'm adding/modifying model fields that require me to make migrations using python [manage.py](https://manage.py) makemigrations and python [manage.py](https://manage.py) migrate command. Here is my current situation so far:
What I was supposed to do
IN LOCAL ENV, to create the migration files,
python manage.py makemigrations
python manage.py migrate
Now commit these newly created files, something like below.
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...
IN PRODUCTION ENV, run only the below command.
python manage.py migrate
What I did so far
IN LOCAL ENV, created the migration files,
python manage.py makemigrations
python manage.py migrate
I committed & pushed the changes to production WITHOUT the created migration file
IN PRODUCTION ENV, ran BOTH commands.
python manage.py makemigrations
python manage.py migrate
The production server successfully added the isActive field to the database and is working fine, but I still have a 0011_user_isActive.py migration file in my local changes that hasn't been staged/committed/pushed to github repo.
And because I ran makemigrations command in production env, it probably created the same migration file that I haven't pushed from local env.
My questions are:
What happens if I push the local migration file to production? Wouldn't it create a conflict when I run migration command on digitalocean console in the future?
How should I fix this situation?
I am just scared I'm going to corrupt/conflict my production database as I'm very inexperienced in databases and have too much to risk at the moment. Would appreciate any tips on best practices when dealing with such situations!
As docs says:
The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.
So it's best practice is to push your migration files and make your local and production migration files sync.
And if you got conflict when pushing migraions files and pulling them, the makemigrations --merge command is for solving that.
Also docs says:
Because migrations are stored in version control, you’ll occasionally come across situations where you and another developer have both committed a migration to the same app at the same time, resulting in two migrations with the same number.
Don’t worry - the numbers are just there for developers’ reference, Django just cares that each migration has a different name. Migrations specify which other migrations they depend on - including earlier migrations in the same app - in the file, so it’s possible to detect when there’s two new migrations for the same app that aren’t ordered.
When this happens, Django will prompt you and give you some options. If it thinks it’s safe enough, it will offer to automatically linearize the two migrations for you. If not, you’ll have to go in and modify the migrations yourself - don’t worry, this isn’t difficult, and is explained more in Migration files below.
Also be aware that in case of updating existed data in production, you can use RunPython in migration file. Read about it here.
Background
Migrating a Django app from Digital Ocean to Heroku. I had problems migrating the data, so I used pg_dump to get the schema and the data of each table. Then ran those scripts in heroku. I loaded my website and I can see the new data coming through.
Problem
Now when I push new code with the Heroku CLI that auto runs the deployment, it fails for this reason: psycopg2.errors.DuplicateTable: relation "django_content_type" already exists
The commands I run are
git add .
git commit -m "some message"
git push heroku master"
The Procfile has release: python manage.py migrate which runs the commands, which I thought about taking it out but when I have migrations to run in the future this will cause an issue.
Any thoughts?
This sent me down a rabbit hole this morning, and I figured it out. I am going to leave the question up since I could not find a similar one.
The issue came down to migrations being out of sync locally and remotely. Following the instructions for the top answer on this post cleared up the issue: Django Heroku Error "Your models have changes that are not yet reflected in a migration"
I'm new to Heroku and I am trying to do my first deploy with a change in my models. Now I already have some important stuff in my app's database that I don't want to lose (I'm using PostgresSQL).
Anyway, I did those few improvement to my app's model and it works alright locally, but when I try to deploy it just gives me the
Internal Server Error: /lares/
ProgrammingError at /lares/
column lares_imovel.referencia does not exist
I am used to throwing makemigrations and migrate locally and than just git push heroku master
Anyway, I also tried the heroku run python manage.py migrate afterwards, but I get the same result every time.
I deleted all my migrations files and created them again for this particular app, still it works locally and the issue remains on production.
Do you guys have any idea why this is happening?
I don't know if any of my code is necessary, I'm pretty sure the problem is not there, but if requested I can post it here.
Thanks!
I have deployed app from github repository to the heroku account of my customer as collaborator but this time I had to add some new models.
However I realized that when I deploy my changes from github heroku does not run makemigrations and migrate.
I I read some answers on stackoverflow and understood this is how it is supposed to be.
However my question is what should I do ? What is the best practise to deploy change models to heroku app. (I assume it is not deleting and recreating my app again since customer already has data there.)
(I am able to run makemigrations and migrate from the bash manually but when I have 30+ deployments it's a pain)
Check out the new feature on Heroku called "Release Phase": https://devcenter.heroku.com/articles/release-phase It will allow you to run migrations during the deployment. Just add whatever command you want to your Procfile, like this:
web: your_web_command
release: python manage.py migrate
The release command will run after your app is done building, and before it's launched.