What are some good best practices to prevent the following.
Often, during django development I use postgres. If I roll back to an earlier commit, often new migrations will break things irreparably, because the postgres context is unknown to the older code. I have tried the syncdb etc, I have tried makemigrations on single apps, but neither seem to fix the problem.
Also, if creating a new postgres db and deleting all the migrations and pycache folders, this too often causes problems that are not straightforward to fix.
Is the answer to simply use sqlite during development, has anyone else encountered this?
Details: django 2.0.5 postgres: most current.
Related
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.
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?
Right now I'm in development so frequently make changes to models, edit, delete, etc.
However often even with makemigrations and migrate Django doesn't pick up on the changes I've made.
Sometimes running python manage.py migrate --run-syncdb will solve it (yes I know this has been depreciated but it still works which is why I use it as a last resort) but sometimes it doesn't and I have to delete the sqlite database and migrate from scratch.
Obviously in production this not going to be possible and I'd like to know the best way to deal with this.
The question that has been suggested to me as a duplicate is from 2012 and the answers are no longer relevant.
I am following online instructions on starting a Django project the right way.
The instructions are based on an earlier version of Django. From my (admittedly limited) knowledge of Django. The latest release of Django (1.10 at the time of posing this question), already handles migrations seemingly well - by way of the manage.py script.
My question then is this: Do I still need to install South to manage my migrations, or can I simply skip that part of the instructions, and use manage.py to deal with my db schema changes?
No, South was for Django before 1.7. With 1.10 everything you would have used it for is baked into Django itself.
My application has been on production for 3 years and the DB model is stable. It seems to me that adding migrations support is more pain that it is worth.
Is it possible/desirable to upgrade without migrations support?
The good old syncdb command is still there. If all you need is to add/drop tables(models), you can continue to use that. The new migration support doesn't make any difference to you if you don't create any migrations (with makemigration and migrate commands).
That said, enabling migration is still recommended. You never know when your schema will change, even for a stable DB model. If you don't like Django's builtin migration solution, try south, which was the de facto standard, and have been proven solid.