So I am developing a django project in an AWS virtual env. To use a package, I need a newer version of Django, but I already have a lot of important data stored in Django's database.
My question is: Will updating the Django version mid-development compromise the data I already have in the database?
I apologize if the question seems stupid, I just really don't mess anything up.
Thanks in advance
The database Django uses is a separate thing (e.g. PostgreSQL, MySQL...), independent from it. Django only interacts with it to write and read data.
Updating Django to a new version might break something in your code if it uses old Django features that have been removed, but it won't affect your database.
Nevertheless, it's always a good idea to backup everything before crucial updates.
Related
I'm just beginning my journey with Django framework and I read that Django developers have made using migrations mandatory beginning from version 2.0. I might be old school but I like my database separate from my code. I have always kept my database separate from my code models. I think that the migrations won't scale with the engineering team size.
So my question is 2 fold.
Can you not use Django 2.0 without the migrations as I don't think it will scale well and won't fit the CI/CD pipeline?
If we can't avoid the db migrations then how can we integrate them in a robust CI/CD pipeline where a model can be changed by different developers from different teams.
Yes, you can. You can create your tables manually and set Django to not manage your tables.
After your Django project is configured, just run on your terminal python manage.py inspectdb > models.py, and django will pick the models on the configured database. This is particularly good if your project will use a already existing or legacy database
Then, you can tell django to not manage your tables on the meta options of the model:
class MyModel(models.Model):
# your fields here
class Meta:
managed = False
See the docs here
But, unless you have a very good way to keep track of your table changes, I must say this is a mistake. Django migrations help you to keep track on your models changes along the way. It is really helpful if you need to rollback or understand your database history.
Migrations are not mandatory, it's not clear what you think has changed in 2.0 to make them so.
Migrations are intended for large teams. If you avoid them, you'll make things much much harder for yourself and your fellow team members.
I have a mobile app frontend using Graphcool as the backend. I currently have two Graphcool project, one for production and the other one for dev. Now I need to migrate the dev version of the database to the production one. To be specific, I need to do the followings:
Update ENUM
Update Schema and make sure it won't break the current data
Update the permission and rules
Update functions
I have tried to copy and paste the new schema from dev to production, but I find out there are many inconsistencies I need to solve manually. Meanwhile, since the project export function currently has no way to backup the permissions and functions, I have to manually change them once step 1 and 2 are finished.
The question is my production project has many live requests and I don't want to have any down time or requests that potentially can break data consistency. What will be the best way to deal with this kind of migration? Are there any guidelines, best practises? Many thanks.
Since I last asked the question, Graphcool has posted a doc to introduce the multi staging workflow. The new cli has included most of the questions I asked.
https://www.graph.cool/docs/tutorials/cli-multi-staging-workflow-ex4wo4zaep/
I would like to define a few PostgreSQL stored procedures in Django for later use, but I cannot find any support from Django to achieve this. I can do this by writing separate python script or SQL file, however I prefer to use Django migration feature. Anyone has done this before?
I have never used stored procedures with Django migration.
However, I am wondering: does it make sense? A stored procedure is not going to change your database schema in most of cases, therefore from my point of view you don't need to make a migration for it
Noob here... :)
I'm working on a small and personal project that is already in "production", but development still is under way. In the last weeks I've managed to handle the updates in a hacky way. Usually, I make a dump of the (still small) database into json files, separed by app or sometimes by table, drop everything in the database, implement the model's changes in json level trough scripts, syncdb a new database, and put everything back on. I known, it's dumb, but I'm lacking knowledge of a better alternative. So, now that I'm borderline insane with this strategy I come to you guys.
I've looked into South, but I failed to understand how exactly is it's workflow regarding the Data migration (in opposition of it's schema migration that is obvious).
So, how do you guys do it?
Thanks in advance.
South creates python scripts. So you can use South to create schema migrations, and then change these scripts to include your own data migration.
If you just add models and fields you don't need to do this, you can just use plain South.
Due to my little confidence with Django and my sheer horror at the thought of seriously messing up my beautiful project, I shall ask for proper advice/instructions here.
The database that my Django project is sitting on top of has been changed (a few field types have been changed) and my models are now out-of-sync. Funnily enough, my Django still works (God knows how) but I still want to update the models. How do I go about doing this the proper way. Thank you very much indeed in advance.
Marked as answered. My actual discover was:
./manage.py inspectdb > <file>
//Hands you all the tables from the database.
//Then you update the models accordingly.
SIMPLE! :)
It's probably a bit late, but you might want to take a look at South, which is a migrations system for Django.
The normal practice for your situation would be to run manage.py reset appname, where appname is the name of the app which contains the models you've changed. You'll obviously want to dump the data in the affected tables first (find out what tables are going to be affected by running manage.py sqlreset appname).
Finally, it's quite possible your site is still running happily because you've not restarted the webserver (I'm assuming you're talking about a production environment, the development server reloads most changes automatically).
If you've already made the changes to the live database, you can probably just change the models and restart your webserver.
As long as your Field names match between the database and the models you shouldn't have any issues.
That being said, it is a much better idea to use a migration tool like south (as Dominic suggested already)