I have been having this issue when managing Django migrations on deployment, and I would like to know what approach should I take:
I am developing an application using Django, and I am using PythonAnywhere to deploy the web app. I am using SQLite as the database. I understand the Django migrations work like a tree or a sequence (001, 002).
Every time I make a change in a field locally, it works fine because the tree has been saved and the sequence has not changed. But when deploying the changes through GitHub (having deployed the web app and calling the migrations and migrate command, which creates another migrations files and sequence), I usually get an error indicating that the migration tree is broken. So I have to go to the app's migration folder, delete them, and call the migrations and migrate commands again.
This is causing me a lot of problems, as I do not want to mess with schema of the database and lose the information.
It is just me or anyone else is having this issue the migrations tree, not only on PythonAnywhere but on others servers?
Thank you!
Thank you guys! #Ankit Tiwari, not I did not as the Django documentation says that it is important to keep the migrations files on deployment as #caseneuve recommended. Even thought I read somewhere that on the server side is not necessary to call the makemigrations command, just the migrate as the migrations files already exist; so I try it and so far it is not giving me more errors. Thanks for the answers.
Related
I've built an app using Django etc. I ran into a whole bunch of problems with database on Heroku after accidentally pushing to production before running heroku run python manage.py makemigrations and heroku run python manage.py migrate.
I decided to just completely destroy the database currently on Heroku and want to recommit my app's models to heroku. My hope is to completely start from a clean slate.
I just want to make sure I do this correctly so I'm asking for clear instructions about how to recommit my app's database to Heroku after destroying the database in the dashboard.
Current error I get when I open my app online is:
settings.DATABASES is improperly configured. Please supply the NAME or OPTIONS['service'] value.
Thanks!
If you completely removed your database you'll have to provision another one. Assuming you are using Heroku Postgres¹, you can do that using the Heroku CLI like so:
heroku addons:create heroku-postgresql:hobby-dev
Here we are asking Heroku to provision the heroku-postgresql add-on using the free hobby-dev tier. Modify as needed.
You can also provision add-ons using the Dashboard if you prefer.
As part of the provisioning process, Heroku Postgres will automatically set a new DATABASE_URL for your app. As long as your project was using this variable before you deleted your old database, it should find the new database without requiring any changes.
¹If you were using a different database add-on the solution should be more or less the same. Provision a new instance of the add-on, let it set its environment variable, and if your app was using that variable before it should pick it up on its own.
While developing a Django project, all your migrations are stored within each app folder, however, in production I don't want those migrations, I want to keep a Production database, and a Development database:
How do I handle Django migrations in a Production and Development environment?
I'm asking this question because it's been really hard to update my deployed project with new additions in the development one, my ideal scenario would be to keep each set of migrations in a folder outside my source code, just like the databases.
The best idea is to keep production and development migrations the same and while developing you clean migrations before pushing the code and you should push migrations into your Version Control System too.
In development, you might end up deleting a table and re-creating it so make sure you don't push the un-intended migrations. The thing is you should treat migrations as code, not an automated script. I have done a lot of mistakes in the past, so, I came to the conclusion of including migrations in code. and that's effective and gives more control.
Moreover you might have to do data migrations in production, how will you do if you wont push the code?
I have a running Django application on Heroku with migrations auto-run on release. While in most times this works fine sometimes there is a problem when:
There are more than one migration in given release (they can be in different apps)
Some migration will fail, but not the first one
In this case manage.py migrate will fail so Heroku will not finish the release and will not deploy the new code. This means that code is in the old version and the database is in the state "somewhere between old and new".
Is there a simple way to autorun Django run reversed migrations in case of the failure of the release command on Heroku?
Transactions won't help here as there might be more than one migration (multiple apps) and Django run each migration in seperate transaction.
As I couldn't find any existing solutions I am posting a gist I have written to solve this.
https://gist.github.com/pax0r/0591855e73b9892c28d3e3cdd15f4985
The code stores the state of migrations before running the migration and in case of any exception reverts back to this state. It also checks if all migrations are reversible during the migrate step.
It's not yet well tested, but I will work forward to create a library from it for easier use by others.
I'm having trouble with my Django-app that's been deployed.
It was working fine but I had to do a minor modification (augmented the max_length) of a Charfield of some model. I did migrations and everything was working fine in the local version.
Then I commited the changes without a problem and the mentioned field of the web version now accepts more characters, as expected, but whenever I click the save button a Server Error rises.
I assume I have to do some kind of migration/DB update for the web version but I don't seem to find how.
(I'm working with Django 1.11, postgresql 9.6, and DigitalOcean).
EDIT
I've just realized that the 'minor modification' also included a field deletion in the model.
Short answer
You have to run
python manage.py migrate
on the server, too. Before you do that, make sure all migration scripts you have locally are also present on the server.
Explanation
After changing the model, you probably locally ran
python manage.py makemigrations
This creates migration scripts that'll transform database schema accordingly. Hopefully, you've committed these newly created scripts to Git, together with the changed model. (If not, you can still do so now.)
after running makemigrations (either before or after committing, that shouldn't matter), you've probably locally ran
python manage.py migrate
This applies the migration scripts to the database that haven't been applied to it, yet. (The information which ones have already been applied is stored in the database itself.)
You probably (and hopefully) haven't checked in your local database into Git, so when you pushed your tracked changes to a remote repo and pulled them down on your server (or however else the new Git revisions got there), the changes to the server database haven't happened, yet. So you have to repeat the last local step (migrate) on the server.
Further reading
For more information, refer to the Django 1.11 documentation w.r.t. migrations. (You can e.g. limit migration creation or migration application to a single Django app, instead of the whole Django project.) To get the grip of these things, I can recomment the free Django Girls tutorial.
I want to add a couple of new fields to my app in Heroku. I wouldn't like to lose the data I have there. So, I tried using South but it kept giving me errors, it looks like I made a mistake somewhere and now I need to delete the migrations and try again. In a local environment this is done by deleting the migrations folder and dropping the south_migrationhistory tables. I am new to Heroku, I guess the commands are similar, but I can't seem to find them. Thanks in advance for your help.
Heroku comes with the ability to run a unix shell remotely, it works pretty much like ssh.
Just type heroku run bash in a terminal (from the git repo of your project of course), and you will end up with a bash prompt that can be used to explore the file system and process environment of your project, including South migration files.
Hope this helps.