Adding new columns in Django models [duplicate] - django

This question already has answers here:
Altering database tables in Django
(7 answers)
Closed 9 years ago.
I have created a sample Django application with multiple models within it and populated data.
Now, I need to add a new column to one of the models?
Here are my concerns?
What will happen if I do syncdb after adding a column to the model , will it just alter the table and add the new column?
Or will it create a new table after deleting all the columns?
Is there any better way to tackle this issue?

syncdb does not work for altering database tables.
Here is the documentation (Readup on : Syncdb will not alter existing tables)
A clean way to achieve this would be to use a 3rd party tool such as django south which would handle the migrations (Handle the alter table scripts in your case) for you.
Here is a step by step tutorial on south, and here is the official documentation on south

syncdb will not add new column and if the table already exist it will not create no new table. the thing i used to do is simply after adding the field name in your model. get within the shell and type:
$ python manage.py dbshell
you will get directly within your database shell (mysql or psql) it up to what database
you are using.
mysql> | psql> ALTER TABLE <table_name> ADD column varchar(100);
and it will add the new column to your table, doesn't matter if the table it already populated or not.

In development, I use the reset function a lot. It's useful for me as I don't mind blowing away dev data. It basically makes new database tables for just that app - so it will remove your data. Not useful if you wish to keep the data populated, south is better as mentioned above.
python manage.py reset <app-name>

Related

Adding new field in Django model

I am currently working on a Django project with around 30 models and there are lots of relations(For example, foreign key relations) between the models.
My doubt is "After 6 months, let's say I want to add a new field(s) in one of the model/table(s) in models.py, and make migrations, the new migration files will get created without affecting the initial migration files which were created 6 months ago."
Will the relations be maintained after adding new columns in different tables? (or) do I have to go to pgadmin console and tweak them accordingly?
One way is to erase all the migrations and start fresh, but this is not recommended often especially if there is production data (or) there are frequent changes in the database schema.
#Mahesh, You may use --fake-initial to avoid the existing tables error at the time of new migrations(When you want to add new column).
Relation will be maintained since you already declared it and unless you change it in a new migration.
How to add a new field to a model with new Django migrations?
And in Docs: https://docs.djangoproject.com/en/3.0/ref/django-admin/#cmdoption-migrate-fake-initial
If you don't change Django version, adding new fields on models will not create any problem, even after many years. But, there are some situations this might create problems. For example, if Django is updated and you have installed the latest version.

Modify the django models

I just tested it myself. I had Django models, and there have already been instances of the models in the database.
Then I added a dummy integer field to a model and ran manage.py syncdb. Checked the database, and nothing happened to the table. I don't see the extra field added in.
Is this the expected behavior? What's the proper way of modifying the model, and how will that alter the data that's already in the database?
Django will not alter already existing tables, they even say so in the documentation. The reason for this is that django can not guarantee that there will be no information lost.
You have two options if you want to change existing tables. Either drop them and run syncdb again, but you will need to store your data somehow if you want to keep it. The other options is to use a migrations tool to do this for you. Django can show you the SQL for the new database schema and you can diff that to the current version of the database to create the update script.
You could even update your database mannually if it is a small change and you don't want to bother with migrations tools, though I would recommend to use one.
Please use south for any kind of changes to get reflected to your database tables,
here goes the link for using south
Link for South documentation

cleaning django db of previous tables

I had a table in Postgres called user that was a custom model. I then switched over to the default Django User class, but there have been issues because of the name overlap. How can I either wipe the previous table, or wipe the entire DB (still in testing, so not a big deal) to start over?
The simplest would be to execute a DROP TABLE statement directly in your database prompt, remember that Django models are just like any other table for your database
dropdb --help
Run this in the terminal

Making a django blog: says database column is missing when 'sql' shows the column exists

here is the error in question:
I've run syncdb and restarted the server.
The "sql" command shows what SQL would be run by syncdb, not what columns actually exist currently in the table; double-check the column existence in a DB tool.
syncdb won't add columns to existing tables, only create brand new ones. You'll want to look at a project like South http://south.aeracode.org/ to manage adding comlumns (or run the alter table add column manually.)

SQL commands generated in Django by running sqlall

In my Django app, I just ran
$ python manage.py sqlall
and I see a lot of SQL statements that look like this, when describing FK relationships:
ALTER TABLE `app1_model1` ADD CONSTRAINT model2_id_refs_id_728de91f FOREIGN KEY (`model2_id`) REFERENCES `app1_model2` (`id`);
Where does "7218de91f" come from? I would like to know because I'd like to manually write SQL statements to accompany models changes in the app so that my db's can be kept up to date.
Why not use a migration app to write all your SQL for you. It's definitely the smart way to go. Check out South -- part of it will be merged into Django core soon