
- Django - Home
- Django - Basics
- Django - Overview
- Django - Environment
- Django - Creating a Project
- Django - Apps Life Cycle
- Django - Creating Views
- Django - URL Mapping
- Django - Index Page
- Django - Templates System
- Django - MVT
- Django - Add Master Template
- Django Admin
- Django Admin - Interface
- Django Admin - Create User
- Django Admin - Include Models
- Django Admin - Set Fields to Display
- Django Admin - Update Objects
- Django Models
- Django - Models
- Django - Insert Data
- Django - Update Data
- Django - Delete Data
- Django - Update Model
- Django Static Files
- Django - Add Static Files
- Django - Add CSS Files
- Django Advanced
- Django - Page not Found (404)
- Django - Page Redirection
- Django - Sending E-mails
- Django - Generic Views
- Django - Form Processing
- Django - File Uploading
- Django - Apache Setup
- Django - Cookies Handling
- Django - Sessions
- Django - Caching
- Django - Comments
- Django - RSS
- Django - AJAX
Django Admin Update Models
Djangos ORM API provides useful functionality for performing CRUD operations on the data stored in the tables of relational databases.
The create(), update() and delete() methods perform their respective operations on an already existing table. However, you often need to make changes to the model structure itself, by adding, deleting or altering the attributes of the model. Djangos admin interface can be helpful in handling these activities.
Django has a powerful migration system that deals with the process of updating a model.
Django propagates the changes you make to your models (adding a field, deleting a model, etc.) into your database schema with the help Migrations mechanism. The migrations-related commands are executed with the "manage.py" script.
The following commands are available −
migrate − Responsible for applying and un-applying the migrations.
makemigrations − Responsible for creating new migrations based on the changes made to the models.
sqlmigrate − Displays the SQL statements for a migration.
showmigrations − Lists a projects migrations and their status.
When you first set up a Django project, it automatically installs a certain apps. They are listed in the INSTALLED_APPS section in the "settings.py" module. Most of these apps are used in the admin interface to create and manage the users, groups, authorization, etc.
The data related to these apps is stored in the respective tables. We need to run the migrate command for the first time to create the table structure required for INSTALLED_APPS
python manage.py migrate
This creates a package called migrations inside the "app package folder". All the subsequent migration scripts are stored in it.
Subsequently, when you create a new app (using the startapp command), you also need to add it in the INSTALLED_APPS list. Next, you declare the models required for the new app. Here, you need to create the database tables required for the new app.
Adding a New Model
Let us add a new model in the "models.py" module as follows −
from django.db import models # Create your models here class Dreamreal(models.Model): website = models.CharField(max_length=50) mail = models.CharField(max_length=50) name = models.CharField(max_length=50) phonenumber = models.IntegerField() def __str__(self): return "Website: {} Email: {} Name: {} Ph.: {}".format(self.website, self.mail, self.name, self.phonenumber) class Meta: db_table = "dreamreal"
To propagate the new model in the database, run the makemigrations command −
python manage.py makemigrations
A migrations script 0001_initial.py will be created in the migrations folder. It contains a Migrations class. The migrate command uses this script to create a new table in the database that has been configured in the DATABASES section of "settings.py".
Python manage.py migrate
Eventually, you decide to add a new model class called employee, as given below −
class Employee(models.Model): eid = models.CharField(max_length=20) ename = models.CharField(max_length=100) eemail = models.EmailField() econtact = models.CharField(max_length=15) class Meta: db_table = "employee"
When you run the makemigrations command again, it creates the second migration script −
D:\workspace\myproject> python manage.py makemigrations myapp Migrations for 'myapp': myapp\migrations\0002_employee.py - Create model Employee
The new migration file 0002_employee.py is applied with the migrate command −
D:\workspace\myproject> python manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, myapp, sessions Running migrations: Applying myapp.0002_employee... OK
If you check in the database structure, the employee table can be found in it.

If you feel it necessary to change the structure of any of the models, you need to run the migrations again.
We drop the "eemail field" and add the "salary field" −
class Employee(models.Model): eid = models.CharField(max_length=20) ename = models.CharField(max_length=100) econtact = models.CharField(max_length=15) salary = models.IntegerField() class Meta: db_table = "employee"
Run the makemigrations command again −
D:\workspace\myproject> python manage.py makemigrations myapp Migrations for 'myapp': myapp\migrations\0003_remove_employee_eemail_employee_salary.py - Remove field eemail from employee - Add field salary to employee
Show the List of Migrations Scripts
The showmigrations command shows the list of migrations scripts generated so far, with the migrations already applied showing [X] mark.
python manage.py showmigrations myapp [X] 0001_initial [X] 0002_employee [ ] 0003_remove_employee_eemail_employee_salary
Run the migrate command again to effect the changes to the employee table −
D:\workspace\myproject> python manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, myapp, sessions Running migrations: Applying myapp.0003_remove_employee_eemail_employee_salary... OK
Rollback the Recent Changes
If you want to roll back the recent changes to the employee table and restore the state of "0002_mployee.py" script,
D:\workspace\myproject> python manage.py migrate myapp 0002_employee Operations to perform: Target specific migration: 0002_employee, from myapp Running migrations: Rendering model states... DONE Unapplying myapp.0003_remove_employee_eemail_employee_salary... OK
Go back and change the structure to confirm that the employee table structure is restored.