This video covers the initial data models for the blog.
- [Instructor] Here we are at the fourth video, Designing the Blog Data Schema. In our previous video, we created our first project. In this video, we'll first activate your application and then we'll create and apply migrations. We will start by defining the initial data models for our blog. A model is a Python class that's subclass is django.db.models.model in which each attributes represents a database field. Django will create a table for each model defined in the models.py file.
When you create a model, Django offers you a practical API to query the database easily. First, we'll define a post model. For that, add these lines to the model.py file of the blog application. This is our basic model for blog posts. Let's take a look at the fields we just defined for this model. Title. This is the field for the post title. This field is Charfield which translates into a var char column in the SQL database. Slug, this is a field intended to be used in URLs.
A slug is a short label containing only letters, numbers, underscores, or hyphens. We'll use these Slug field to build beautiful SCO friendly URL's for our blog posts. We have added the unique four date parameters to this field so we can build URL's for posts using the date and slug of the post. Django will prevent multiple posts having these same slug for the same date. Author. This field is foreign key. This field defines a many to one relationship.
We're telling Django that each pose is written by user and a user can write several posts. For this field, Django will create a foreign key in the database using the primary key of the related model. In this case, we're relying on the user model of the Django authentication system. We specify the name of the reverse relationship from user to post with the related name attribute. We're going to learn more about this later. Body. This is the body of the post. This field is text field which translates into a text column in the SQL database.
Publish. This date time indicates when the post was published. We use Django's time zone now method as default value. This is just a time zone where date time.now Created. This date time indicates when the post was created. Since we are using auto now add here, the date will be saved automatically when creating an object. Updated. This date time indicates the last time the post has been updated. Since we are using auto now here, the date will be updated automatically when saving an object.
Status. This is a field to show the status of a post. We use a choices parameter so the value of this field can only be set to one of the given choices. As you can see, Django comes with different types of fields that you can use to define your models. You can find all field types at this web page. The class meta inside the model contains the meta data. We are telling Django to sort results by the publish field in descending order by default when we clear the database.
We specify descending order using the negative prefix. The string method is the default human readable representation of the object. Django will use it in many places such as the administration site. If you come from Python 2.x note that in Python 3, all strings are natively considered Unicode. Therefore, we only use the string method. The Unicode method is obsolete. Since we're going to deal with date times we'll install the pyt.zed module. This module provides time zone definitions for Python.
And as required by SQ Lite to work with date times. Open the shell, and install pyt zed with the help of the command, pip install, pyt zed. Here you can see that it's installed. Django comes with support for time zone aware date times. You can activate or deactivate time zone support with the use_tzed setting in the settings.py file of your project. This setting is set to true when you create a new project. He's in the Start Project management command. Now let's activate the application.
In order for Django to keep track of our application, and be able to create database tables for its models, we have to activate it. To do this, edit the settings.py file. Add blog to the installed apps setting. It should look like this. Now Django knows that our application is active for this project and we're able to introspect his models. We'll now create and apply migrations. Let's create a data table for our model in the database. Django comes with a migration system to track the changes you do to your models and propagate them into the database.
The migrate command applies migrations for all applications listed in installed apps. It synchronizes the database with the current models and migrations. For that, we first need to create a migration for the new model we just created. Open the command prompt. From the root directory of your project, enter this command. You should get this output. 0001_initial.py file has been migrated. Django just created a file 0001initial.py inside the migrations directory of the blog application.
You can open that file to see how a migration looks like. Let's take a look at the SQL code that Django while executing the database to create the table for our model. The SQL migrate command takes migration names and returns their SQL without running it. Run this command to inspect it's output. The output should look as follows. The exact output depends on the database you are using. The output here is generated for SQLite. As you can see, Django generates the table names by combining the app name and the lower case name of the model blog_post but you can also specify them in the meta class or the model using the DB table attribute.
Django creates a primary key automatically for each model but you can also waive (mumbles) specifying primary key equals true on one of your model fields. Let's sync our database with the new model. For that, let's run this command to apply existing migrations. You'll get this output that ends with the line that is shown. We just applied migrations for the applications listed in installed apps including our blog application. After applying migrations, the database reflects the current status of our models.
If you edit your models.py file in order to add, remove, or change fields of existing models or if you add new models, you'll have to make a new migration using the Make Migrations command. The migration will allow Django to keep track of model changes. Then you'll have to apply it with the migrate command to keep your database in sync with your models. Awesome. Here we saw how to design the blog data schema. In our next video, we'll see how to create an administration sight for your models.
Note: This course was created by Packt Publishing. We are pleased to host this training in our library.
- Building a blog application
- Creating an administration site for your models
- Creating templates for your views
- Using class-based views
- Enhancing your blog with advanced features
- Creating and handling forms
- Adding tagging functionality
- Extending your blog application
- Creating custom template tags and filters