![\"Django](\"https:\/\/data-flair.training\/blogs\/wp-content\/uploads\/sites\/2\/2019\/07\/Django-Migrations.jpg\")
<\/a><\/p>\nAwesome!! We have so much information to grasp. So, let’s explore it.<\/p>\n
Databases and Django<\/h3>\n
A database is a collection of data arranged in an efficient way. It ensures fast and secure storage, access and update of data.<\/em> That is, the main concept of every type of database is both paper registers and MySQL.<\/p>\n There are many types of databases out there. We will be narrowing them down to relational databases. Now, what\u2019s that? A relational database is a collection of tables having a number of columns and rows.<\/em><\/p>\n Yes, there are databases that actually don\u2019t use columns and rows. So, whatever databases we have worked with on the web is a relational database. These databases can have relational tables or fields. We have used Foreign Key Field in our Django projects.<\/p>\n Here, we are creating a post involving a Foreign Key for Post Table.<\/p>\n This is a snapshot of the models.py<\/strong> file of our project.<\/p>\n SQL (Structured Query Language) is a very popular language for databases. Almost all the popular databases use SQL. The databases like PostgreSQL, MySQL, SQLite, etc. are some of many examples.<\/p>\n The databases mentioned above are relational databases. Yes, the majority of SQL databases are relational and are extensively used in the industry.<\/p>\n What\u2019s special about PostgreSQL, MySQL, etc. is that they have native support from Django. SQLite3 is the one that comes installed out of the box, although, you will have to install the software for other databases. Django ORM will handle the rest according to the backend engine used.<\/p>\n We will discuss the configuration of these databases in a separate article. It will provide you with all the required information and Django settings. Now, let\u2019s learn some important configuration of settings for databases.<\/p>\n These are common settings you should know to connect database with Django project. This code exists in the\u00a0settings.py file.<\/strong><\/p>\n Here is the snapshot of the default code that Django provides.<\/p>\n Basically, database settings for your project reside in a Python Dictionary<\/strong><\/em>. The name of the dictionary is DATABASE<\/strong>. This dictionary and some of its attributes are\u00a0pre-defined.<\/p>\n The default key<\/strong> is pre-defined, which contains configuration settings for a default database. Since Django can work with multiple databases, you can have multiple database configurations.<\/p>\n The default key is required to configure a single or multiple databases. Inside the default value, key resides the configuration for the database.<\/p>\n The configuration can vary for different types of the database you are using.<\/p>\n The default value is:<\/strong><\/p>\n Now, these keys have different values for different databases. This configuration is for SQLite database.<\/p>\n The ENGINE<\/strong> Key<\/strong> is used to specify the database backend. This will connect the Django project to SQLite Database. You can use other backends too. For that, you have to provide additional keys. We will configure these databases in a separate article.<\/p>\n Note:<\/strong><\/p>\n Django comes with these four database backends natively. These databases will require their database software but the backend is in-house.<\/p>\n PostgreSQL:<\/strong><\/p>\n MySQL:<\/strong><\/p>\n SQLite:<\/strong><\/p>\n Oracle:<\/strong><\/p>\n These backends will be able to implement all the latest features of Django<\/strong><\/em>. They are developed and maintained by the DSF (Django Software Foundation)<\/strong>. You can use other backends as well. In that case, you have to import the full package path of that backend.<\/p>\n Since Django has a vast community, you can get backends for all kinds of databases.<\/p>\n The NAME<\/strong> Key<\/strong> contains the name of the database. For SQLite, you can directly use this database. For databases like MySQL or PostgreSQL, you need to create the database first.<\/p>\n So, these were two important fields for configuring databases in Django. You can complete our Django Database DataFlair tutorial<\/strong><\/em> to implement the code in this tutorial.<\/p>\n In this section, we are going to understand how these databases work with Django. After you have configured your database settings and checked that everything is working fine, see what happens under the hood.<\/p>\n When we start our Django project, it loads the settings.py<\/strong> file on the server. This file contains all information and even database configurations.<\/p>\n Then Django will load the Database Backend. That backend will connect to the default database configured in settings. It is done by passing appropriate key values to the Database Software.<\/p>\n The database then verifies the values and the connection is established. The connection is between the Database Backend and Database. The backend becomes a mediator between Database and Django.<\/p>\n All the built-in backends are very efficient and are used in a production environment.<\/p>\n Now, the database is connected and we can easily migrate our models and create tables in the same. The backend also handles all the CRUD operations from Django on the database.<\/p>\n Migrations were not present in Django versions before version 1.7. Let\u2019s learn how developers dealt with the situation.<\/p>\n When migrations were introduced for the first time in Django, it became a huge hit. Django\u2019s popularity grew exponentially. This proves migrations are a very important feature.<\/p>\n So, when there were no migrations in Django, developers had some difficulties.<\/p>\n They had to define the tables and database schemas according to models. Now, this may seem easy in listening but SQL is quite difficult. This became more complex when they had to create models with foreign key relations in them.<\/p>\n This also led to occasional errors and database inconsistency. The development was much slower than it is today. The developers would also have to keep track of all the changes they made themselves which was very difficult.<\/p>\n The process of reverting back was the same time-consuming experience.<\/p>\n These were some of the many problems faced by developers with no migrations.<\/p>\n Migrations resolved\u00a0all of them and also some additional features were provided. Let\u2019s learn in-depth about these features and solutions.<\/p>\n In the previous section, we learned that SQL is used to create a Database Schema. That has to be the same as Models that we defined in our application. Writing SQL with the same constraints as our Models is difficult. It requires a decent knowledge of SQL.<\/p>\n Django solved this problem with the introduction of Django ORM or Object-relational Mapper<\/strong>. An ORM as its name will map the Model Fields to Database Table Fields\/ Columns.<\/p>\n The model has 3 fields namely date, price, volume.<\/strong> These are defined in Python with model class attributes. Django ORM generates the table. It also defines corresponding fields and constraints.<\/p>\n The example table has fields mapped to the table. There is an extra field that works as a primary key. This is an awesome feature of Django ORM. It defines a primary key automatically if we haven\u2019t defined our own. This has saved a lot of developers from database errors.<\/p>\n Django ORM does this via migrations. So, what are migrations?<\/p>\n Django migrations are nothing but Python Files<\/strong><\/em>. They contain Python code which is used by Django ORM to create and alter tables and fields in the database.<\/p>\n Django implements Models and changes to them on the database via migrations. Django generates migrations automatically. This is a key feature and you should also take care of these. Migrations are not meant to be corrected in normal conditions.<\/p>\n You can modify them but the file is accurate most of the time. We have used migrations every time we used a Model.<\/p>\n Migrations had a huge impact on the development process of web apps. They have greatly reduced the errors in one of the most error-prone areas by migrations.<\/p>\n This has made it easier for beginners to work with a database with no experience in SQL or databases. It has also increased the utility of Django and made the developer\u2019s life easier. Some of these main benefits of migrations are as follows:<\/p>\n We have used MySQL and phpMyAdmin which is a graphical tool for databases. If we had used SQL instead, then making tables would become more complex.<\/p>\n For beginner developers, this could pose a real problem. Migrations had made Django more fun to use. It lets us bypass the whole SQL writing and makes tables automatically.<\/p>\n This was the most error-prone zone for backend developers. Since they had to make the Database Schema same as the Models. It would take complex SQL and thus, resulting in errors. Sometimes, they can be real security threats but this is not the case with migrations.<\/p>\n Since migrations generate SQL automatically, it is always correct. That SQL contains the same constraints, we define in Models. We can see that SQL is generated by Django ORM in a later section.<\/p>\n DRY philosophy is one of the core principles in which Django is based on. Since Django is a framework for rapid development, this feature is an essential pillar.<\/p>\n Django migrations automatically generate SQL. This means developers won\u2019t need to write the same code again. Not repeating the code makes the whole development fast.<\/p>\n Migrations are Python files. Django generates a new migration file every time we modify a model. These files are not deleted and stored inside the app directory.<\/p>\n These files contain very simple codes. It is easy for a developer to understand what changes were made. This also makes it easy to revert back to previous Models.<\/p>\n Django migrations have several benefits, these were some important ones. We can now learn some very basic operations on migrations. We have used most of them in our previous Django tutorials.<\/p>\n These are some of the common Django migration operations which you must know. These commands will give you an edge in handling Database Management System (DBMS). Migration is a trending topic for Django interviews. You will surely find this knowledge worthwhile.<\/p>\n We will make a new application to implement these operations. In your Terminal\/ PowerShell prompt, execute this command to make a new application.<\/p>\n Terminal Screen Display:<\/strong><\/p>\n You will have to install this app in settings.py.<\/strong>\u00a0Add this app\u2019s name in INSTALLED_APPS<\/strong> list.<\/p>\n Now, in Cars\/models.py<\/strong> file paste this code:<\/p>\n Code Display:<\/strong><\/p>\n We created a very simple model for cars. There are 3 fields namely name, price, and weight<\/strong>. Now we will implement all the operations on this model one by one.<\/p>\n Note:<\/strong><\/p>\n It is important that your Django project has a database configured and running. To configure database settings, please visit the Django Database tutorial<\/strong>. There you can easily set up the database and proceed with this tutorial.<\/em><\/p>\n We have done this process, every time we use a model. We will now create the migration files which will then be used by the ORM to create tables. Just run this command:<\/p>\n Terminal Screen Display:<\/strong><\/p>\n Thus, we have a Migration file ready. The name of this file is\u00a00001_initial.py.<\/strong> Django automatically serializes the migration files with a numerical value. This file contains the migration class.<\/p>\n Although, at our level, we need not do any modification on it.<\/p>\n We created migrations in the previous file. Now, its time to apply them. We need to understand the difference. In the previous section, we just created some Python files.<\/p>\n These files will not affect the database until we apply them.<\/p>\n This command will apply migrations in the database.<\/p>\n Terminal Screen Display:<\/strong><\/p>\n This command can also take the name of a specific application. Django has made it so easy for us to apply migrations.<\/p>\n Migrate command can apply all the migrations at once if no parameter is given.<\/p>\n It is special because it will not apply unchanged migrations. So, if developers had changed only a particular model, they can simply write migrate.<\/p>\n It is important that you execute makemigrations<\/strong> before migrate<\/strong> command. Since a migration file is required before applying it to the database.<\/p>\n Now, we can check our database for this table.<\/p>\n There we have a table of cars_specs<\/strong>. If you check the structure, you will notice one extra field – Id field.<\/p>\n This is created automatically by Django ORM for the purpose of a primary key. We can define a primary key in Models for a particular field. It\u2019s the default behaviour of Django ORM.<\/p>\n Every relational database requires a primary key in a table, otherwise, your table is not created. Django creators knew this very well and thus provided us with migrations functionality.<\/p>\n Website growth is not linear. As the website grows, there will be changes in Database Schema. So, when we change our models, we will again execute these commands:<\/p>\n makemigrations<\/strong> and migrate<\/strong> in their respective order.<\/p>\n It is necessary for the Model definition to match the Database Schema. Otherwise, we will get an OperationalError<\/strong>.<\/p>\n Now, we will change the specs model<\/strong>. As weight is not always an integer, we change it to decimal.<\/p>\n Paste this Code in cars\/models.py:<\/strong><\/p>\n Code Display:<\/strong><\/p>\n To apply this change, we will again run the commands.<\/p>\n This should be the output. Let\u2019s see the database table.<\/p>\n As we can clearly see, if we had to change the same manually, it would have been a time-consuming affair.<\/p>\n We all love the undo<\/em> option. It reverts back the previous state and saves our time. Django also gives us an option to revert back. Suppose you are working on production site and made some change to the Database Schema.<\/p>\n Change may not yield positive results as you were expecting. Then, it will be time-consuming to change the Models again as the previous schema. Also, this can be more prone to errors, if you do it manually. Django allows you to revert back to any previous migration. The feature is important as it will change the Database Schema. That means you don\u2019t need to rewrite anything.<\/p>\n This can be easily achieved with migrate<\/strong> command. This time you don\u2019t need to perform makemigrations<\/strong> command since the file already exists.<\/p>\n Now, use this command:<\/p>\n Terminal Screen Display:<\/strong><\/p>\n When we ran this command, we passed some parameters. The first parameter is the application name. In this case, it was Cars<\/strong>. The second parameter is the migration<\/strong> file<\/strong> name.<\/p>\n We passed a number 0001, then the name of the file. This is one of the cool features of Django. It will match the file with the matching string 0001. Since it is a primary key for Django, therefore there are no conflicts. You can also use a complete name, the result will be the same.<\/p>\n Let\u2019s take a look at the database structure now.<\/p>\n The weight field has again reverted back to an integer.<\/p>\n Note:<\/strong><\/p>\n Although I compared undo operation with reverting migrations; it is not the same. When we apply another migration, it will revert back the Database Schema. That is the only part which is undone.<\/p>\n Suppose, you have added some fields which were not there in previous Models. Now, when you revert back the schema changed, the data which was saved in the new fields were deleted. This is the difference. Therefore, always be vary when modifying databases.<\/p>\n When we reverted from this migration, the file was not deleted. The migration files are never deleted by Django. So, you have to be careful when applying migrations again. migrate<\/strong> command will automatically apply last migrations of the app.<\/p>\n You can either delete that file or apply the migration to apps specific.<\/p>\n When applications became too big, this operation comes in handy. It will list out all the migrations, existing in the Django project. We can be specific to applications like in\u00a0migrate<\/strong> command.<\/p>\n The command:<\/p>\n Terminal Screen Display:<\/strong><\/p>\n This command will show all the migrations if no parameter is given. The Cars application has 2 migration files. Their names are listed out.<\/p>\n You can notice that [X]<\/strong> in front of the 0001_initial<\/strong> file. The X<\/strong> represents that migrations have been applied. We just reverted the migration to 0001. The second migration is unapplied, therefore [ ]. <\/strong><\/p>\n It helps to determine which migrations are applied in the current database.<\/p>\n This command is mostly used when you are working in teams. Since many people are applying migrations, a developer can easily check which migrations exists and work accordingly.<\/p>\n Migrations can be a user named too. This operation will let you provide meaningful names to migration. It is used at the time of creating migrations.<\/p>\n The command:<\/p>\n Since we are not changing anything in our models, we will delete the migration file.<\/p>\n You have to do this manually.<\/p>\n Now execute the above command.<\/p>\n<\/a><\/p>\nConfiguring Settings for Django Database<\/h4>\n
<\/a><\/p>\nDATABASES = {\r\n 'default': {\r\n 'ENGINE': 'django.db.backends.sqlite3',\r\n 'NAME': 'mydatabase',\r\n }\r\n}<\/pre>\ndjango.db.backends.postgresql<\/pre>\n
django.db.backends.mysql<\/pre>\n
django.db.backends.sqlite3<\/pre>\n
django.db.backends.oracle<\/pre>\n
How these Databases Work with Django<\/h4>\n
Problems Solved by Django Migrations<\/h4>\n
Django Migrations<\/strong><\/h3>\n
Key Benefits of Django Migrations<\/h4>\n
\n
\n
\n
\n
Common Django Migration Operations<\/h4>\n
Setting up Application<\/h4>\n
python manage.py startapp Cars<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\nfrom django.db import models\r\n#DataFlair #DataBaseMigrations\r\n\r\nclass Specs(models.Model):\r\n name = models.CharField(max_length = 20)\r\n price = models.DecimalField(max_digits=8, decimal_places=2)\r\n weight = models.PositiveIntegerField()\r\n<\/pre>\n
<\/a><\/p>\n1. Creating Migrations<\/h5>\n
python manage.py makemigrations Cars<\/pre>\n
<\/a><\/p>\n2. Applying Migrations<\/h4>\n
python manage.py migrate Cars<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n3. Editing Models<\/h4>\n
from django.db import models\r\n#DataFlair #DataBaseMigrations\r\n# Create your models here.\r\n\r\nclass Specs(models.Model):\r\n name = models.CharField(max_length = 20)\r\n price = models.DecimalField(max_digits=8, decimal_places=2)\r\n weight = models.DecimalField(max_digits=7, decimal_places=3)<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/h5>\n4. Reverting Migrations<\/h4>\n
python manage.py migrate Cars 0001<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\n5. Indexing all Migrations<\/h4>\n
python manage.py showmigrations Cars<\/pre>\n
<\/a><\/p>\n6. Naming Migrations<\/h4>\n
python manage.py makemigrations Cars -- the name change<\/pre>\n
\n