[Day 9] Creating a model

January 14, 2021 ← Last time: Display template in Day 8 Template View

Precautionary statement

This article is not a single article. I wrote it as a diary, so I think it will be useful for those who are new to it. If you want to learn Django, we recommend reading it from [Day 1] Django Development Environment.

Introduction

The theme this time is "Creating a model". So far, it's very rudimentary, but we've looked at View and Template. The rest is Model. Django has a mechanism that allows you to link with a database and perform validation processing smartly by giving various information to the model. This time, let's make a simple model and learn because it is a bulletin board.

Add thread application

First, create a thread application. This is an application that handles things related to bulletin board threads.

(venv)$ ./manage.py startapp thread

Add thread/urls.py, add application to mysite/settings.py, and add URL to mysite/urls.py as well as base application. This area is similar to the base application. [Day 4] Application Creation For reference

mysite/settings.py

  INSTALLED_APPS = [
      'django.contrib.admin',
      'django.contrib.auth',
      'django.contrib.contenttypes',
      'django.contrib.sessions',
      'django.contrib.messages',
      'django.contrib.staticfiles',
      'django.contrib.sites',
      'django.contrib.sitemaps',
      'debug_toolbar',
      'base',
+     'thread',
  ]

mysite/urls.py

  urlpatterns = [
      path('admin/', admin.site.urls),
      path('', include('base.urls')),
+     path('thread/', include('thread.urls')),
  ]

thread/urls.py

from django.urls import path

from . import views
app_name = 'thread'

urlpatterns = [
]

Now the additional processing of the application is OK.

Model addition

The thread application model is assumed to be as follows. First, consider the following model so that it has the minimum functions of the bulletin board.

thread/models.py

from django.db import models

class TopicManager(models.Manager):
    #Added processing related to Topic operation
    pass

class CommentManager(models.Manager):
    #Added processing related to Comment operation
    pass

class CategoryManager(models.Manager):
    #Added processing related to Category operation
    pass

class Category(models.Model):
    name = models.CharField(
        'Category name',
        max_length=50,
    )
    url_code = models.CharField(
        'URL code',
        max_length=50,
        null=True,
        blank=False,
        unique=True,
    )
    sort=models.IntegerField(
        verbose_name='sort',
        default=0,
    )
    objects = CategoryManager

    def __str__(self):
        return self.name

class Topic(models.Model):
    user_name = models.CharField(
        'name',
        max_length=30,
        null=True,
        blank=False,
    )
    title = models.CharField(
        'title',
        max_length=255,
        null = False,
        blank = False,
    )
    message = models.TextField(
        verbose_name='Text',
        null=True,
        blank=False,
    )
    category = models.ForeignKey(
        Category,
        verbose_name='Category',
        on_delete=models.PROTECT,
        null=True,
        blank=False,
    )
    created = models.DateTimeField(
        auto_now_add=True,
    )
    modified = models.DateTimeField(
        auto_now=True,
    )
    objects = TopicManager()

    def __str__(self):
        return self.title

class Comment(models.Model):
    id = models.BigAutoField(
        primary_key=True,
    )
    no = models.IntegerField(
        default=0,
    )
    user_name = models.CharField(
        'name',
        max_length=30,
        null=True,
        blank=False,
    )
    topic = models.ForeignKey(
        Topic,
        on_delete=models.PROTECT,
    )
    message = models.TextField(
        verbose_name='Posted content'
    )
    pub_flg = models.BooleanField(
        default=True,
    )
    created = models.DateTimeField(
        auto_now_add=True,
    )
    objects = CommentManager()

    def __str__(self):
        return '{}-{}'.format(self.topic.id, self.no)

Brief commentary

From here, we will enter the above (thread/models.py) explanation. Therefore, I will post the URL of the head family. Honke After that, I will put the explanation below so that you do not have to jump to the link, but since it is exactly the same as the head family, it is recommended to fly to the head family and refer to it.

Model field

The properties of each class in the model are defined by the model fields. The official model field reference summarizes the model field types. In Django, it is ideal to collect the related information of the model in one place as much as possible, and add information such as data type at the time of database storage, relation information, default value, null tolerance, etc. In many Web developments, I think that implementation will start after completing API design and database design, so it will be a task to write the design straight to the model.

null and blank

I got null and blank. Does null allow nulls on the database? And blank is whether or not the user makes it a required item as an input item. Specifically, if you apply False to blank, the input tag will be required in the form.

Automatic ID generation

By the way, did you notice that there is no description about ID? If you don't specify the ID, Django will automatically generate it for you. In that case, the data type will be int and the Primary Key will be set.

Foreign key

This time, in order to build a one-to-many relationship, the topic has the category id and the comment has the topic id. In such cases, Django uses a Foreign Key. In that case, specify the deletion method with on_delete when the model held as a foreign key is deleted. The types are as follows.

models.CASCADE: Models referenced along with foreign key models are also deleted models.PROTECT: Protected (cannot be deleted if referenced) models.SET_NULL: ID will be NULL if the foreign key model is deleted models.SET_DEFAULT: The value set by default is set. Is PROTECT recommended? CASCADE is a little risky, but I don't think it's a problem depending on the design.

About the manager

In addition, this time we prepared TopicManager, CommentManager, CategoryManager and linked them with objects of each model. In the future, we will add processing related to operations related to each model to this manager, and call that processing from the view so that it acts on the model. Before I get used to it, View tends to do a lot of processing and it tends to be bloated, but I am thinking (with self-admonition) that the business logic processing that the model is responsible for should be done by the model. So far, I was able to explain it carefully, but I wasn't sure. However, I did understand what Django's model was like. # in conclusion This time I created a model. Having touched SQL at university, I was able to understand the nature of the model a little.

See you again

← Last time: Display template in Day 8 Template View → Next time: Day 10 Database Migration