When you start a new app, the first thing that you do is create the models that represent your database structure. We are assuming that you have already created Django apps, or, at the very least, have read and understood the official Django tutorial. In this chapter, you will see a few interesting techniques that will make your database structure consistent throughout the different apps in your project. Then, you will see how to create custom model fields, in order to handle the internationalization of the data in your database. At the end of the chapter, you will see how to use migrations to change your database structure during the process of development.

In object-oriented languages, such as Python, a mixin class can be viewed as an interface with implemented features. When a model extends a mixin, it implements the interface and includes all of its fields, properties, and methods. The mixins in Django models can be used when you want to reuse the generic functionalities in different models multiple times.

First, you will need to create reusable mixins. A good place to keep your model mixins is in a utils module, such as the one that we will create later in the chapter (along with some typical examples of mixins). If you create a reusable app that you will share with others, keep the model mixins in the reusable app, instead—possibly...

For every model that is appropriate to detail on its own distinct page, it is a good practice to define the get_absolute_url() method. This method can be used in templates, and also in the Django admin site, to preview the saved object. However, get_absolute_url() is ambiguous, as it returns the URL path instead of the full URL.

In this recipe, we will look at how to create a model mixin that provides simplified support for model-specific URLs. This mixin will:

• Allow you to define either the URL path or the full URL in your model
• Generate the other of these automatically based on the one you define
• Define the get_absolute_url() method behind the scenes

If you...

It is common to include timestamps in your models, for the creation and modification of your model instances. In this recipe, you will learn how to create a simple model mixin that saves the creation and modification dates and times for your model. Using such a mixin will ensure that all of the models use the same field names for the timestamps, and have the same behaviors.

If you haven't yet done so, create the utils package to save your mixins. Then, create the models.py file in the utils package.

When you optimize your site for search engines, you not only have to use semantic markup for each page, but you also have to include appropriate meta tags. For maximum flexibility, it helps to have a way to define content for common meta tags, specific to objects that have their own detail pages on your website. In this recipe, we will look at how to create a model mixin for the fields and methods related to keyword, description, author, and copyright meta tags.

As detailed in the previous recipes, make sure that you have the utils package for your mixins. Also, create a directory structure, templates/utils, under the package, and inside of that, create a meta...

Aside from normal database relationships, such as a foreign-key relationship or a many-to-many relationship, Django has a mechanism to relate a model to an instance of any other model. This concept is called generic relations. For each generic relation, there is a content type of the related model that is saved, as well as the ID of the instance of that model.

In this recipe, we will look at how to abstract the creation of generic relations in the model mixins.

For this recipe to work, you will need to have the contenttypes app installed. It should be in the INSTALLED_APPS directory, by default, as shown in the following code:

# settings.py or config/base.py
INSTALLED_APPS...

Django uses the internationalization mechanism to translate verbose strings in the code and templates. However, it's up to the developer to decide how to implement the multilingual content in the models. There are several third-party modules that handle translatable model fields; however, I prefer the simple solution that will be introduced to you in this recipe.

The advantages of the approach that you will learn about are as follows:

• It is straightforward to define multilingual fields in the database.
• It is simple to use the multilingual fields in database queries.
• You can use contributed administration to edit models with the multilingual fields, without additional modifications.
• If you need it, you can easily show all of the translations of an object in the same template.
• You can use database migrations to add or remove languages.

The content delivered in a web application is generally very rich, but there are often important details embedded within plain human-readable text, and search engines cannot easily understand them. When such additional information becomes available, though, search result entries for the content can be similarly enriched, increasing SEO rankings and making it easier for users to find what they are looking for.

Part of this is the data that we exposed in the Creating a model mixin to take care of meta tags recipe, earlier in the chapter; however, for certain types of objects, you can build something even more structured. To make this possible, you can identify schema microdata, as per the https://schema.org specification, for objects that are represented in the application. In this recipe, we will approach the creation of a model mixin for...

It is not true that once you have created your database structure, it won't change in the future. As development happens iteratively, you can get updates on the business requirements in the development process, and you will have to perform database schema changes along the way. With Django migrations, you don't have to change the database tables and fields manually, as most of it is done automatically, using the command-line interface.

Activate your virtual environment or Docker project in the command-line tool.

If you were using Django before version 1.7 introduced database migrations into the core functionality, you have more than likely used third-party South migrations before. In this recipe, you will learn how to switch your project from South migrations to Django migrations.

Make sure that all apps, along with their South migrations, are up to date.

Execute the following steps:

1. Migrate all of your apps to the latest South migrations, as follows:

(myproject_env)$ python3 manage.py migrate...

This recipe is a practical example of how to change a many-to-one relation to a many-to-many relation, while preserving the already existing data. We will use both schema and data migrations in this situation.

Let's suppose that you have the Idea model, with a foreign key pointing to the Category model, as follows:

# demo_app/models.py 
from django.db import models 
from django.utils.translation import ugettext_lazy as _ 
 
class Category(models.Model):
    title = models.CharField(_("Title"), max_length=200)

    def __str__(self):
        return self.title
 
class Idea(models.Model):
    title = model.CharField(
        _("Title"),
   ...