So, locally I've changed my models a few times and used South to get everything working. I have a postgres database to power my live site, and one model keeps triggering a column mainsite_message.spam does not exist error. But when I run heroku run python manage.py migrate mainsite from the terminal, I get Nothing to migrate. All my migrations have been pushed.
Get the list of migrations available for your apps (it will mark what are pending and what others are migrated).
heroku run python manage.py migrate <your app name> --list
if you have migrated with --fake, then identify the number of migration is pending (0003, for example) then do a revert of migrations to get the the previous state:
heroku run python manage.py migrate <your_app_name> 0002 --fake
now try again to migrate.
heroku run python manage.py migrate <your app name>
Did you run schemamigration before? If yes, go to your database and take a look at your table "south_migrationhistory" there you can see what happened.
If you already did the steps above you should try to open your migration file and take a look as well, there you can find if the creation column is specified or not!
I presume that you have created a migration to add mainsite_message.spam to the schema. Have you made sure that this migration is in your git repository?
If you type git status you should see untracked files. If the migration is untracked you need to git add path_to_migration and then push it to Heroku before you can run it there.
Related
I deployed my application to Heroku, but I am not able to add any data.
When I tried to open first table with data from model I received this error message:
ProgrammingError at /category/category_table
relation "tables_category" does not exist
LINE 1: SELECT COUNT(*) AS "__count" FROM "tables_category"
And when I tried to add first data I received this error message:
ProgrammingError at /admin/tables/category/add/
relation "tables_category" does not exist
LINE 1: INSERT INTO "tables_category" ("category_name") VALUES ('sho...
I went through similar Q/A here, but they do not solve my issue, as I have:
a) deleted all migration files from my local disk, then
b) I run: python3 manage.py makemigrations
c) I run: heroku run python3 manage.py migrate
So all should be up to date and I have this log from Heroku:
Operations to perform:
Apply all migrations: admin, auth, contenttypes, sessions, tables
Running migrations:
No migrations to apply.
So currently do not know what to do.
Don't delete migrations
The first step here is very dangerous:
I have... deleted all migration files from my local disk
It is very likely that the new migrations you generate won't work on your local machine. They will attempt to migrate from an empty database to whatever your current state is, but you (presumably) already have tables and maybe even data in your local database from earlier migrations.
Deleting migrations is almost never the right answer. I know a lot of people recommend it whenever you get into migration trouble, but they are wrong. Throwing away your database might feel safe during early development, but it definitely isn't desirable when you have real data later on.
I strongly suggest that you restore your old migration files, then generate new migrations on top of them.
Generating and applying migrations
When you run
python3 manage.py makemigrations
you generate new migration files on your local machine. Heroku has no idea that they exist, so running
heroku run python3 manage.py migrate
won't do anything.
After cerating migrations on your local machine, apply them locally by running python manage.py migrate to make sure they do what they're supposed to do. When you're happy with them, commit the files, redeploy to Heroku, and then run the migrations on Heroku.
So I have deployed my Django project to Heroku, and now trying to migrate the database. I have everything working fine in my local sever. Then I tried to run the commands in heroku, as below.
heroku run python manage.py makemigrations app_name'.
This worked fine.
Migrations for 'app_name':
contents\migrations\0001_initial.py
- Create model Book
- Create model Category
- Create model Content
Then of course, I tried : heroku run python manage.py migrate app_name.
But then I got this error CommandError: App 'app_name' does not have migrations.
I've done some research for possible issues, none of which were relevant to mine.
For example I do have __init__.py in the migrations folder inside app_name directory. Also, I've tried heroku run python manage.py migrate as well as heroku run python manage.py migrate app_name. I'm very confused. What do you think is the problem? Thanks in advance. :)
I had the same problem, I don't know why, but the following works for me (two commands in one line):
python manage.py makemigrations && python manage.py migrate app_name
As explained in heroku's help article Why are my file uploads missing/deleted?:
The Heroku filesystem is ephemeral - that means that any changes to
the filesystem whilst the dyno is running only last until that dyno is
shut down or restarted.
That is you do generate the migration files but they cease to exist shortly after when the app is reloaded.
In general the strategy you take is not a good approach to migrations as this can cause various issues, let's say you have multiple production servers each generates their own migrations this causes a conflict! In your situation suppose you do migrate this way and then later you want to add some new models this again will cause you problems.
One should always add their migrations to the version control (git, etc.) commit them and push them to production (here your heroku dyno). That is run python manage.py makemigrations locally, commit the generated migrations, push them and then run heroku run python manage.py migrate.
i have pushed my django application to heroku
and when i tried to fireup the url where my application is
i just got this error
ProgrammingError at /
relation "accounts_user" does not exist
LINE 1: ..."."is_active", "accounts_user"."date_joined" FROM "accounts_...
so i have figured out that the issue is with migration so i tried to run the makemigrations command in heroku
but unfortunately it returned as a failure with an error message
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration posts.0001_initial is applied before its dependency accounts.0001_initial on database 'default'.
so what i have tried is i have completely removed the migrations and database and runnned makemigration and migrate command in my local server and then i pushed it back to heroku but still its of no use
my local is running perfectly fine
i'm not sure where exactly the migrations issue is , in my heroku django application
i want to remove the previous migrations and have a clean database
but i have no idea on how to do that
I was facing the same issue yesterday. I was using Django rest and sqlite3 DB.
To solve that error I have clear all migration and delete a migration folder and clear DB file. After that, I have run migrations specific for that module and then run migrate command then it works fine for me. I hope it will work for you as well.
e.g.
$ python manage.py makemigrations module_name
$ python manage.py migrate module_name
I mistakenly deleted all the .py file under path projectName/appName/migrations, it include like:
0001_initial.py
0011_auto_20150918_0723.py
0002_auto_20150819_1301.py
...
Now, even I updated the Model file, and run the command python manage.py makemigrations, it always prompt with No changes detected.
How can I recover everything?
First of all, even if this happened to you in production, do not panic.
When you deleted all migrations django forgot that this app is supposed to be managed by migrations. Django defaults back to the legacy python manage.py syncdb migrationless behaviour and will not attempt to detect changes or generate new migrations when you run python manage.py makemigrations
In order to make it aware of the migrations, you have to run the command specifically for your app:
python manage.py makemigrations appName
However, for your running application, django will not be able to detect that the new migrations were already applied in the database, and will try to run them again when you run python manage.py migrate.
When this happens the migrations fail saying that the relation appName.XYZ already exists!.
To make django understand that your migration is already reflected in the database you have to fake them:
python manage.py migrate appName --fake
This will update the migration history table and mark your migrations as applied, but will not attempt to create the tables in the database.
Update (thanks to #GwynBleiD):
One concern here is that deleted migrations which were already applied, will be listed in the migrations history table in the database. This will not be a problem for the initial python manage.py makemigrations myApp, however for any other migrations it will raise an error about inconsistent migration history.
To avoid that, you must remove by hand any row from django_migrations table in database that refers to nonexistent migrations.
I want to revert my last migration (0157) by running its Migration.backwards() method. Since I am reverting the migration in production server I want to run it automatically during code deployment. Deployment script executes these steps:
Pull code changes
Run migrations: manage.py migrate <app>
Refresh Apache to use newest code: touch django.wsgi
If I could, I would create new migration file which would tell South to backward migrate to 0156:
migrations/0158_backward__migrate_to_0156.py
This commited migration would be deployed to production and executed during manage.py migrate <app> command. In this case I wouldn't have to execute backward migration by hand, like suggested in these answers.
Lets say, I have created two data migrations, first for user's Payment, second for User model. I have implemented backwards() methods for both migrations in case I'd have to revert these data migrations. I've deployed these two migrations to production. And suddenly find out that Payment migration contains an error. I want to revert my two last data migrations as fast as possible. What is the fastest safe way to do it?
Since I am reverting the migration in production server I want to run
it automatically during code deployment.
IMHO the safest path is
run manage.py migrate <app> (i.e. apply all existing migrations, i.e. up to 0156)
undo the changes in your model
run manage.py schemamigration <app> --auto
This will create a new migration 0157 that effectively reverts the previous migration 0156. Then simply apply the new migration by running manage.py migrate <app> again. As I understand, your code deployment will just do that.
Apparently the codeline has migrations up to #157 and now the developer decided that the last one was not a good idea after all. So the plan is to go back to #156.
Two scenarios:
(a) migration #157 was not released or deployed anywhere yet.
Simply revert the last change from models.py and delete migration #157.py from the source archive. Any deployment will take the system to level 156; "157 was never there".
(b) there have been deployments of the latest software with migration #157.
In this case the previous strategy will obviously not work. So you need to create a migration #158 to undo #157. Revert the change in models.py and run
django manage.py migrate <app> 0157
django manage.py schemamigration <app> --auto
This will auto-generate a new migration #158, which will contain the inverse schema migration compared to #157.
If schemamigration is giving trouble because of django Model validation (something that can happen if you have custom validators which check stuff outside the ORM box), I suggest the following workaround:
<django project>/<app>/management/commands/checkmigrations.py
from south.management.commands import schemamigration
class Command(schemamigration.Command):
requires_model_validation = False
help = "schemamigration without model validation"
This command becomes available in manage.py:
django manage.py checkmigrations <app> --auto
There's no silver bullet here. The simplest solution I can think of would be to - in your dev env of course - manually migrate back to 0156, manually update your migration's history table (sorry I can't remember the table's name now) to fool south in thinking you're still #0158, then run schemamigration again. Not garanteed to work but might be worth trying.