What You Should Know About The Django User Model

How to Start a Production-Ready Django Project

Chart.js is a cool open source JavaScript library that helps you render HTML5 charts. It is responsive and counts with
8 different chart types.
In this tutorial we are going to explore a little bit of how to make Django talk with Chart.js and render some simple
charts based on data extracted from our models.
Installation
For this tutorial all you are going to do is add the Chart.js lib to your HTML page:
<script src="https://cdn.jsdelivr.net/npm/chart.js@2.9.3/dist/Chart.min.js"></script>


You can download it from Chart.js official website and use it locally, or you can use it from a CDN using the URL above.
Example Scenario
I’m going to use the same example I used for the tutorial How to Create Group By Queries With Django ORM which is a good complement to this tutorial because actually the tricky part of working with charts is to transform the data so it can fit in a bar chart / line chart / etc.
We are going to use the two models below, Country and City:
class Country(models.Model):
 name = models.CharField(max_length=30)

class City(models.Model):
 name = models.CharField(max_length=30)
 country = models.ForeignKey(Country, on_delete=models.CASCADE)
 population = models.PositiveIntegerField()


And the raw data stored in the database:
cities
 
 
id
 name
 country_id
 population
 
1Tokyo2836,923,000
2Shanghai1334,000,000
3Jakarta1930,000,000
4Seoul2125,514,000
5Guangzhou1325,000,000
6Beijing1324,900,000
7Karachi2224,300,000
8Shenzhen1323,300,000
9Delhi2521,753,486
10Mexico City2421,339,781
11Lagos921,000,000
12São Paulo120,935,204
13Mumbai2520,748,395
14New York City2020,092,883
15Osaka2819,342,000
16Wuhan1319,000,000
17Chengdu1318,100,000
18Dhaka417,151,925
19Chongqing1317,000,000
20Tianjin1315,400,000
21Kolkata2514,617,882
22Tehran1114,595,904
23Istanbul214,377,018
24London2614,031,830
25Hangzhou1313,400,000
26Los Angeles2013,262,220
27Buenos Aires813,074,000
28Xi'an1312,900,000
29Paris612,405,426
30Changzhou1312,400,000
31Shantou1312,000,000
32Rio de Janeiro111,973,505
33Manila1811,855,975
34Nanjing1311,700,000
35Rhine-Ruhr1611,470,000
36Jinan1311,000,000
37Bangalore2510,576,167
38Harbin1310,500,000
39Lima79,886,647
40Zhengzhou139,700,000
41Qingdao139,600,000
42Chicago209,554,598
43Nagoya289,107,000
44Chennai258,917,749
45Bangkok158,305,218
46Bogotá277,878,783
47Hyderabad257,749,334
48Shenyang137,700,000
49Wenzhou137,600,000
50Nanchang137,400,000
51Hong Kong137,298,600
52Taipei297,045,488
53Dallas–Fort Worth206,954,330
54Santiago146,683,852
55Luanda236,542,944
56Houston206,490,180
57Madrid176,378,297
58Ahmedabad256,352,254
59Toronto56,055,724
60Philadelphia206,051,170
61Washington, D.C.206,033,737
62Miami205,929,819
63Belo Horizonte15,767,414
64Atlanta205,614,323
65Singapore125,535,000
66Barcelona175,445,616
67Munich165,203,738
68Stuttgart165,200,000
69Ankara25,150,072
70Hamburg165,100,000
71Pune255,049,968
72Berlin165,005,216
73Guadalajara244,796,050
74Boston204,732,161
75Sydney105,000,500
76San Francisco204,594,060
77Surat254,585,367
78Phoenix204,489,109
79Monterrey244,477,614
80Inland Empire204,441,890
81Rome34,321,244
82Detroit204,296,611
83Milan34,267,946
84Melbourne104,650,000
countries
 
 
id
 name
 
1Brazil
2Turkey
3Italy
4Bangladesh
5Canada
6France
7Peru
8Argentina
9Nigeria
10Australia
11Iran
12Singapore
13China
14Chile
15Thailand
16Germany
17Spain
18Philippines
19Indonesia
20United States
21South Korea
22Pakistan
23Angola
24Mexico
25India
26United Kingdom
27Colombia
28Japan
29Taiwan
Example 1: Pie Chart
For the first example we are only going to retrieve the top 5 most populous cities and render it as a pie chart.
In this strategy we are going to return the chart data as part of the view context and inject the results in the
JavaScript code using the Django Template language.
views.py
from django.shortcuts import render
from mysite.core.models import City

def pie_chart(request):
 labels = []
 data = []

 queryset = City.objects.order_by('-population')[:5]
 for city in queryset:
 labels.append(city.name)
 data.append(city.population)

 return render(request, 'pie_chart.html', {
 'labels': labels,
 'data': data,
 })


Basically in the view above we are iterating through the City queryset and building a list of labels and a list of
data. Here in this case the data is the population count saved in the City model.
For the urls.py just a simple routing:
urls.py
from django.urls import path
from mysite.core import views

urlpatterns = [
 path('pie-chart/', views.pie_chart, name='pie-chart'),
]


Now the template. I got a basic snippet from the Chart.js Pie Chart Documentation.
pie_chart.html
{% extends 'base.html' %}

{% block content %}
 <div id="container" style="width: 75%;">
 <canvas id="pie-chart"></canvas>
 </div>

 <script src="https://cdn.jsdelivr.net/npm/chart.js@2.9.3/dist/Chart.min.js"></script>
 <script>

 var config = {
 type: 'pie',
 data: {
 datasets: [{
 data: {{ data|safe }},
 backgroundColor: [
 '#696969', '#808080', '#A9A9A9', '#C0C0C0', '#D3D3D3'
 ],
 label: 'Population'
 }],
 labels: {{ labels|safe }}
 },
 options: {
 responsive: true
 }
 };

 window.onload = function() {
 var ctx = document.getElementById('pie-chart').getContext('2d');
 window.myPie = new Chart(ctx, config);
 };

 </script>

{% endblock %}


In the example above the base.html template is not important but you can see it in the code example I shared in the
end of this post.
This strategy is not ideal but works fine. The bad thing is that we are using the Django Template Language to interfere
with the JavaScript logic. When we put {{ data|safe}} we are injecting a variable that came from
the server directly in the JavaScript code.
The code above looks like this:

Example 2: Bar Chart with Ajax
As the title says, we are now going to render a bar chart using an async call.
views.py
from django.shortcuts import render
from django.db.models import Sum
from django.http import JsonResponse
from mysite.core.models import City

def home(request):
 return render(request, 'home.html')

def population_chart(request):
 labels = []
 data = []

 queryset = City.objects.values('country__name').annotate(country_population=Sum('population')).order_by('-country_population')
 for entry in queryset:
 labels.append(entry['country__name'])
 data.append(entry['country_population'])
 
 return JsonResponse(data={
 'labels': labels,
 'data': data,
 })


So here we are using two views. The home view would be the main page where the chart would be loaded at. The other
view population_chart would be the one with the sole responsibility to aggregate the data the return a JSON response
with the labels and data.
If you are wondering about what this queryset is doing, it is grouping the cities by the country and aggregating the
total population of each country. The result is going to be a list of country + total population. To learn more about
this kind of query have a look on this post: How to Create Group By Queries With Django ORM
urls.py
from django.urls import path
from mysite.core import views

urlpatterns = [
 path('', views.home, name='home'),
 path('population-chart/', views.population_chart, name='population-chart'),
]


home.html
{% extends 'base.html' %}

{% block content %}

 <div id="container" style="width: 75%;">
 <canvas id="population-chart" data-url="{% url 'population-chart' %}"></canvas>
 </div>

 <script src="https://code.jquery.com/jquery-3.4.1.min.js"></script>
 <script src="https://cdn.jsdelivr.net/npm/chart.js@2.9.3/dist/Chart.min.js"></script>
 <script>

 $(function () {

 var $populationChart = $("#population-chart");
 $.ajax({
 url: $populationChart.data("url"),
 success: function (data) {

 var ctx = $populationChart[0].getContext("2d");

 new Chart(ctx, {
 type: 'bar',
 data: {
 labels: data.labels,
 datasets: [{
 label: 'Population',
 backgroundColor: 'blue',
 data: data.data
 }] 
 },
 options: {
 responsive: true,
 legend: {
 position: 'top',
 },
 title: {
 display: true,
 text: 'Population Bar Chart'
 }
 }
 });

 }
 });

 });

 </script>

{% endblock %}


Now we have a better separation of concerns. Looking at the chart container:
<canvas id="population-chart" data-url="{% url 'population-chart' %}"></canvas>


We added a reference to the URL that holds the chart rendering logic. Later on we are using it to execute the Ajax call.
var $populationChart = $("#population-chart");
$.ajax({
 url: $populationChart.data("url"),
 success: function (data) {
 // ...
 }
});


Inside the success callback we then finally execute the Chart.js related code using the JsonResponse data.

Conclusions
I hope this tutorial helped you to get started with working with charts using Chart.js. I published another tutorial
on the same subject a while ago but using the Highcharts library. The approach is pretty much the same: 
How to Integrate Highcharts.js with Django.
If you want to grab the code I used in this tutorial you can find it here: github.com/sibtc/django-chartjs-example.

How to Use Chart.js with Django

In this tutorial you are going to learn how to pass extra data to your serializer, before saving it to the database.

<ul>
 <li><a href="#introduction">Introduction</a></li>
 <li><a href="#example-using-apiview">Example Using APIView</a></li>
 <li><a href="#example-using-viewset">Example Using ViewSet</a></li>
</ul>

<h3 id="introduction">Introduction</h3>

When using regular Django forms, there is this common pattern where we save the form with <code class="highlighter-rouge">commit=False</code> and then pass
some extra data to the instance before saving it to the database, like this:

<figure class="highlight"><pre><code class="language-python" data-lang="python">form = InvoiceForm(request.POST)
if form.is_valid():
 invoice = form.save(commit=False)
 invoice.user = request.user
 invoice.save()</code></pre></figure>

This is very useful because we can save the required information using only one database query and it also make it 
possible to handle not nullable columns that was not defined in the form.

To simulate this pattern using a Django REST Framework serializer you can do something like this:

<figure class="highlight"><pre><code class="language-python" data-lang="python">serializer = InvoiceSerializer(data=request.data)
if serializer.is_valid():
 serializer.save(user=request.user)</code></pre></figure>

You can also pass several parameters at once:

<figure class="highlight"><pre><code class="language-python" data-lang="python">serializer = InvoiceSerializer(data=request.data)
if serializer.is_valid():
 serializer.save(user=request.user, date=timezone.now(), status='sent')</code></pre></figure>

<hr />

<h3 id="example-using-apiview">Example Using APIView</h3>

In this example I created an app named <code class="highlighter-rouge">core</code>.

models.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from django.contrib.auth.models import User
from django.db import models

class Invoice(models.Model):
 SENT = 1
 PAID = 2
 VOID = 3
 STATUS_CHOICES = (
 (SENT, 'sent'),
 (PAID, 'paid'),
 (VOID, 'void'),
 )

 user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='invoices')
 number = models.CharField(max_length=30)
 date = models.DateTimeField(auto_now_add=True)
 status = models.PositiveSmallIntegerField(choices=STATUS_CHOICES)
 amount = models.DecimalField(max_digits=10, decimal_places=2)</code></pre></figure>

serializers.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from rest_framework import serializers
from core.models import Invoice

class InvoiceSerializer(serializers.ModelSerializer):
 class Meta:
 model = Invoice
 fields = ('number', 'amount')</code></pre></figure>

views.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from rest_framework import status
from rest_framework.response import Response
from rest_framework.views import APIView
from core.models import Invoice
from core.serializers import InvoiceSerializer

class InvoiceAPIView(APIView):
 def post(self, request):
 serializer = InvoiceSerializer(data=request.data)
 serializer.is_valid(raise_exception=True)
 serializer.save(user=request.user, status=Invoice.SENT)
 return Response(status=status.HTTP_201_CREATED)</code></pre></figure>

<hr />

<h3 id="example-using-viewset">Example Using ViewSet</h3>

Very similar example, using the same models.py and serializers.py as in the previous example.

views.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from rest_framework.viewsets import ModelViewSet
from core.models import Invoice
from core.serializers import InvoiceSerializer

class InvoiceViewSet(ModelViewSet):
 queryset = Invoice.objects.all()
 serializer_class = InvoiceSerializer

 def perform_create(self, serializer):
 serializer.save(user=self.request.user, status=Invoice.SENT)</code></pre></figure>

In this tutorial you are going to learn how to pass extra data to your serializer, before saving it to the database.
Introduction
Example Using APIView
Example Using ViewSet
Introduction
When using regular Django forms, there is this common pattern where we save the form with commit=False and then pass
some extra data to the instance before saving it to the database, like this:
form = InvoiceForm(request.POST)
if form.is_valid():
    invoice = form.save(commit=False)
    invoice.user = request.user
    invoice.save()


This is very useful because we can save the required information using only one database query and it also make it 
possible to handle not nullable columns that was not defined in the form.
To simulate this pattern using a Django REST Framework serializer you can do something like this:
serializer = InvoiceSerializer(data=request.data)
if serializer.is_valid():
    serializer.save(user=request.user)


You can also pass several parameters at once:
serializer = InvoiceSerializer(data=request.data)
if serializer.is_valid():
    serializer.save(user=request.user, date=timezone.now(), status='sent')




Example Using APIView
In this example I created an app named core.
models.py
from django.contrib.auth.models import User
from django.db import models

class Invoice(models.Model):
    SENT = 1
    PAID = 2
    VOID = 3
    STATUS_CHOICES = (
        (SENT, 'sent'),
        (PAID, 'paid'),
        (VOID, 'void'),
    )

    user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='invoices')
    number = models.CharField(max_length=30)
    date = models.DateTimeField(auto_now_add=True)
    status = models.PositiveSmallIntegerField(choices=STATUS_CHOICES)
    amount = models.DecimalField(max_digits=10, decimal_places=2)


serializers.py
from rest_framework import serializers
from core.models import Invoice

class InvoiceSerializer(serializers.ModelSerializer):
    class Meta:
        model = Invoice
        fields = ('number', 'amount')


views.py
from rest_framework import status
from rest_framework.response import Response
from rest_framework.views import APIView
from core.models import Invoice
from core.serializers import InvoiceSerializer

class InvoiceAPIView(APIView):
    def post(self, request):
        serializer = InvoiceSerializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        serializer.save(user=request.user, status=Invoice.SENT)
        return Response(status=status.HTTP_201_CREATED)




Example Using ViewSet
Very similar example, using the same models.py and serializers.py as in the previous example.
views.py
from rest_framework.viewsets import ModelViewSet
from core.models import Invoice
from core.serializers import InvoiceSerializer

class InvoiceViewSet(ModelViewSet):
    queryset = Invoice.objects.all()
    serializer_class = InvoiceSerializer

    def perform_create(self, serializer):
        serializer.save(user=self.request.user, status=Invoice.SENT)

How to Save Extra Data to a Django REST Framework Serializer

In this tutorial we are going to explore three date/datetime pickers options that you can easily use in a Django 
project. We are going to explore how to do it manually first, then how to set up a custom widget and finally how to
use a third-party Django app with support to datetime pickers.
Introduction
Tempus Dominus Bootstrap 4
 
Direct Usage
Custom Widget
XDSoft DateTimePicker
 
Direct Usage
Custom Widget
Fengyuan Chen’s Datepicker
 
Direct Usage
Custom Widget
Conclusions
Introduction
The implementation of a date picker is mostly done on the front-end.
The key part of the implementation is to assure Django will receive the date input value in the correct format, and 
also that Django will be able to reproduce the format when rendering a form with initial data.
We can also use custom widgets to provide a deeper integration between the front-end and back-end and also to promote
better reuse throughout a project.
In the next sections we are going to explore following date pickers:
Tempus Dominus Bootstrap 4
Docs 
Source 

XDSoft DateTimePicker
Docs 
Source 

Fengyuan Chen’s Datepicker
Docs 
Source 

Tempus Dominus Bootstrap 4
Docs 
Source 
This is a great JavaScript library and it integrate well with Bootstrap 4. The downside is that it requires moment.js
and sort of need Font-Awesome for the icons.
It only make sense to use this library with you are already using Bootstrap 4 + jQuery, otherwise the list of CSS and JS
may look a little bit overwhelming.
To install it you can use their CDN or download the 
latest release from their GitHub Releases page.
If you downloaded the code from the releases page, grab the processed code from the build/ folder.
Below, a static HTML example of the datepicker:
<!doctype html>
<html lang="en">
 <head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
 <title>Static Example</title>

 
 <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.2.1/css/bootstrap.min.css" integrity="sha384-GJzZqFGwb1QTTN6wy59ffF1BuGJpLSa9DkKMp0DgiMDm4iYMj70gZWKYbI706tWS" crossorigin="anonymous">
 <script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
 <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.6/umd/popper.min.js" integrity="sha384-wHAiFfRlMFy6i5SRaxvfOCifBUQy1xHdJ/yoi7FRNXMRBu5WHdZYu1hA6ZOblgut" crossorigin="anonymous"></script>
 <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.2.1/js/bootstrap.min.js" integrity="sha384-B0UglyR+jN6CkvvICOB2joaf5I4l3gm9GU6Hc1og6Ls7i6U/mkkaduKaBhlAXv9k" crossorigin="anonymous"></script>

 
 <link href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" rel="stylesheet" integrity="sha384-wvfXpqpZZVQGK6TAh5PVlGOfQNHSoD2xbE+QkPxCAFlNEevoEH3Sl0sibVcOQVnN" crossorigin="anonymous">

 
 <script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.23.0/moment.min.js" integrity="sha256-VBLiveTKyUZMEzJd6z2mhfxIqz3ZATCuVMawPZGzIfA=" crossorigin="anonymous"></script>

 
 <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/tempusdominus-bootstrap-4/5.1.2/css/tempusdominus-bootstrap-4.min.css" integrity="sha256-XPTBwC3SBoWHSmKasAk01c08M6sIA5gF5+sRxqak2Qs=" crossorigin="anonymous" />
 <script src="https://cdnjs.cloudflare.com/ajax/libs/tempusdominus-bootstrap-4/5.1.2/js/tempusdominus-bootstrap-4.min.js" integrity="sha256-z0oKYg6xiLq3yJGsp/LsY9XykbweQlHl42jHv2XTBz4=" crossorigin="anonymous"></script>

 </head>
 <body>

 <div class="input-group date" id="datetimepicker1" data-target-input="nearest">
 <input type="text" class="form-control datetimepicker-input" data-target="#datetimepicker1"/>
 <div class="input-group-append" data-target="#datetimepicker1" data-toggle="datetimepicker">
 <div class="input-group-text"></div>
 </div>
 </div>

 <script>
 $(function () {
 $("#datetimepicker1").datetimepicker();
 });
 </script>

 </body>
</html>



 

 
Direct Usage
The challenge now is to have this input snippet integrated with a Django form.
forms.py
from django import forms

class DateForm(forms.Form):
 date = forms.DateTimeField(
 input_formats=['%d/%m/%Y %H:%M'],
 widget=forms.DateTimeInput(attrs={
 'class': 'form-control datetimepicker-input',
 'data-target': '#datetimepicker1'
 })
 )


template
<div class="input-group date" id="datetimepicker1" data-target-input="nearest">
 {{ form.date }}
 <div class="input-group-append" data-target="#datetimepicker1" data-toggle="datetimepicker">
 <div class="input-group-text"></div>
 </div>
</div>

<script>
 $(function () {
 $("#datetimepicker1").datetimepicker({
 format: 'DD/MM/YYYY HH:mm',
 });
 });
</script>


The script tag can be placed anywhere because the snippet $(function () { ... }); will run the datetimepicker 
initialization when the page is ready. The only requirement is that this script tag is placed after the jQuery script
tag.
Custom Widget
You can create the widget in any app you want, here I’m going to consider we have a Django app named core.
core/widgets.py
from django.forms import DateTimeInput

class BootstrapDateTimePickerInput(DateTimeInput):
 template_name = 'widgets/bootstrap_datetimepicker.html'

 def get_context(self, name, value, attrs):
 datetimepicker_id = 'datetimepicker_{name}'.format(name=name)
 if attrs is None:
 attrs = dict()
 attrs['data-target'] = '#{id}'.format(id=datetimepicker_id)
 attrs['class'] = 'form-control datetimepicker-input'
 context = super().get_context(name, value, attrs)
 context['widget']['datetimepicker_id'] = datetimepicker_id
 return context


In the implementation above we generate a unique ID datetimepicker_id and also include it in the widget context.
Then the front-end implementation is done inside the widget HTML snippet.
widgets/bootstrap_datetimepicker.html
<div class="input-group date" id="{{ widget.datetimepicker_id }}" data-target-input="nearest">
 {% include "django/forms/widgets/input.html" %}
 <div class="input-group-append" data-target="#{{ widget.datetimepicker_id }}" data-toggle="datetimepicker">
 <div class="input-group-text"></div>
 </div>
</div>

<script>
 $(function () {
 $("#{{ widget.datetimepicker_id }}").datetimepicker({
 format: 'DD/MM/YYYY HH:mm',
 });
 });
</script>


Note how we make use of the built-in django/forms/widgets/input.html template.
Now the usage:
core/forms.py
from .widgets import BootstrapDateTimePickerInput

class DateForm(forms.Form):
 date = forms.DateTimeField(
 input_formats=['%d/%m/%Y %H:%M'], 
 widget=BootstrapDateTimePickerInput()
 )


Now simply render the field:
template
{{ form.date }}


The good thing about having the widget is that your form could have several date fields using the widget and you
could simply render the whole form like:
<form method="post">
 {% csrf_token %}
 {{ form.as_p }}
 <input type="submit" value="Submit">
</form>




XDSoft DateTimePicker
Docs 
Source 
The XDSoft DateTimePicker is a very versatile date picker and doesn’t rely on moment.js or Bootstrap, although it looks
good in a Bootstrap website.
It is easy to use and it is very straightforward.
You can download the source from GitHub releases page.
Below, a static example so you can see the minimum requirements and how all the pieces come together:
<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
 <title>Static Example</title>

 
 <script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>

 
 <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/jquery-datetimepicker/2.5.20/jquery.datetimepicker.min.css" integrity="sha256-DOS9W6NR+NFe1fUhEE0PGKY/fubbUCnOfTje2JMDw3Y=" crossorigin="anonymous" />
 <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery-datetimepicker/2.5.20/jquery.datetimepicker.full.min.js" integrity="sha256-FEqEelWI3WouFOo2VWP/uJfs1y8KJ++FLh2Lbqc8SJk=" crossorigin="anonymous"></script>
</head>
<body>

 <input id="datetimepicker" type="text">

 <script>
 $(function () {
 $("#datetimepicker").datetimepicker();
 });
 </script>

</body>
</html>



 

 
Direct Usage
A basic integration with Django would look like this:
forms.py
from django import forms

class DateForm(forms.Form):
 date = forms.DateTimeField(input_formats=['%d/%m/%Y %H:%M'])


Simple form, default widget, nothing special.
Now using it on the template:
template
{{ form.date }}

<script>
 $(function () {
 $("#id_date").datetimepicker({
 format: 'd/m/Y H:i',
 });
 });
</script>


The id_date is the default ID Django generates for the form fields (id_ + name).
Custom Widget
core/widgets.py
from django.forms import DateTimeInput

class XDSoftDateTimePickerInput(DateTimeInput):
 template_name = 'widgets/xdsoft_datetimepicker.html'


widgets/xdsoft_datetimepicker.html
{% include "django/forms/widgets/input.html" %}

<script>
 $(function () {
 $("input[name='{{ widget.name }}']").datetimepicker({
 format: 'd/m/Y H:i',
 });
 });
</script>


To have a more generic implementation, this time we are selecting the field to initialize the component using its name
instead of its id, should the user change the id prefix.
Now the usage:
core/forms.py
from django import forms
from .widgets import XDSoftDateTimePickerInput

class DateForm(forms.Form):
 date = forms.DateTimeField(
 input_formats=['%d/%m/%Y %H:%M'], 
 widget=XDSoftDateTimePickerInput()
 )


template
{{ form.date }}




Fengyuan Chen’s Datepicker
Docs 
Source 
This is a very beautiful and minimalist date picker. Unfortunately there is no time support. But if you only need dates
this is a great choice.
To install this datepicker you can either use their CDN or download the 
sources from their GitHub releases page. Please note that they
do not provide a compiled/processed JavaScript files. But you can download those to your local machine using the CDN.
<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
 <title>Static Example</title>
 <style>body {font-family: Arial, sans-serif;}</style>
 
 
 <script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>

 
 <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/datepicker/0.6.5/datepicker.min.css" integrity="sha256-b88RdwbRJEzRx95nCuuva+hO5ExvXXnpX+78h8DjyOE=" crossorigin="anonymous" />
 <script src="https://cdnjs.cloudflare.com/ajax/libs/datepicker/0.6.5/datepicker.min.js" integrity="sha256-/7FLTdzP6CfC1VBAj/rsp3Rinuuu9leMRGd354hvk0k=" crossorigin="anonymous"></script>
</head>
<body>

 <input id="datepicker">

 <script>
 $(function () {
 $("#datepicker").datepicker();
 });
 </script>

</body>
</html>



 

 
Direct Usage
A basic integration with Django (note that we are now using DateField instead of DateTimeField):
forms.py
from django import forms

class DateForm(forms.Form):
 date = forms.DateTimeField(input_formats=['%d/%m/%Y %H:%M'])


template
{{ form.date }}

<script>
 $(function () {
 $("#id_date").datepicker({
 format:'dd/mm/yyyy',
 });
 });
</script>


Custom Widget
core/widgets.py
from django.forms import DateInput

class FengyuanChenDatePickerInput(DateInput):
 template_name = 'widgets/fengyuanchen_datepicker.html'


widgets/fengyuanchen_datepicker.html
{% include "django/forms/widgets/input.html" %}

<script>
 $(function () {
 $("input[name='{{ widget.name }}']").datepicker({
 format:'dd/mm/yyyy',
 });
 });
</script>


Usage:
core/forms.py
from django import forms
from .widgets import FengyuanChenDatePickerInput

class DateForm(forms.Form):
 date = forms.DateTimeField(
 input_formats=['%d/%m/%Y %H:%M'], 
 widget=FengyuanChenDatePickerInput()
 )


template
{{ form.date }}




Conclusions
The implementation is very similar no matter what date/datetime picker you are using. Hopefully this tutorial provided
some insights on how to integrate this kind of frontend library to a Django project.
As always, the best source of information about each of those libraries are their official documentation.
I also created an example project to show the usage and implementation of the widgets for each of the libraries 
presented in this tutorial. Grab the source code at github.com/sibtc/django-datetimepicker-example.

How to Use Date Picker with Django

The Django forms API have two field types to work with multiple options: <code class="highlighter-rouge">ChoiceField</code> and <code class="highlighter-rouge">ModelChoiceField</code>.

Both use select input as the default widget and they work in a similar way, except that <code class="highlighter-rouge">ModelChoiceField</code> is designed 
to handle QuerySets and work with foreign key relationships.

A basic implementation using a <code class="highlighter-rouge">ChoiceField</code> would be:

<div class="row" id="ChoiceField">
 <div class="eight columns">


<figure class="highlight"><pre><code class="language-python" data-lang="python">class ExpenseForm(forms.Form):
 CHOICES = (
 (11, 'Credit Card'),
 (12, 'Student Loans'),
 (13, 'Taxes'),
 (21, 'Books'),
 (22, 'Games'),
 (31, 'Groceries'),
 (32, 'Restaurants'),
 )
 amount = forms.DecimalField()
 date = forms.DateField()
 category = forms.ChoiceField(choices=CHOICES)</code></pre></figure>


 </div>
 <div class="four columns">
 <img src="https://simpleisbetterthancomplex.com/media/2019/01/form.jpg" alt="Django ChoiceField" style="max-width:100%;" />
 </div>
</div>

<hr />

<h4 id="grouped-choice-field">Grouped Choice Field</h4>

You can also organize the choices in groups to generate the <code class="highlighter-rouge">&lt;optgroup&gt;</code> tags like this:

<div class="row">
 <div class="eight columns">


<figure class="highlight"><pre><code class="language-python" data-lang="python">class ExpenseForm(forms.Form):
 CHOICES = (
 ('Debt', (
 (11, 'Credit Card'),
 (12, 'Student Loans'),
 (13, 'Taxes'),
 )),
 ('Entertainment', (
 (21, 'Books'),
 (22, 'Games'),
 )),
 ('Everyday', (
 (31, 'Groceries'),
 (32, 'Restaurants'),
 )),
 )
 amount = forms.DecimalField()
 date = forms.DateField()
 category = forms.ChoiceField(choices=CHOICES)</code></pre></figure>


 </div>
 <div class="four columns">
 <img src="https://simpleisbetterthancomplex.com/media/2019/01/form2.jpg" alt="Django Grouped ChoiceField" style="max-width:100%;" />
 </div>
</div>

<hr />

<h4 id="grouped-model-choice-field">Grouped Model Choice Field</h4>

When you are using a <code class="highlighter-rouge">ModelChoiceField</code> unfortunately there is no built-in solution.

Recently I found a nice solution on <a href="https://code.djangoproject.com/ticket/27331">Django’s ticket tracker</a>, where 
someone proposed adding an <code class="highlighter-rouge">opt_group</code> argument to the <code class="highlighter-rouge">ModelChoiceField</code>.

While the discussion is still ongoing, <a href="https://code.djangoproject.com/ticket/27331#comment:7">Simon Charette</a> proposed
a really good solution.

Let’s see how we can integrate it in our project.

First consider the following models:

models.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from django.db import models

class Category(models.Model):
 name = models.CharField(max_length=30)
 parent = models.ForeignKey('Category', on_delete=models.CASCADE, null=True)

 def __str__(self):
 return self.name

class Expense(models.Model):
 amount = models.DecimalField(max_digits=10, decimal_places=2)
 date = models.DateField()
 category = models.ForeignKey(Category, on_delete=models.CASCADE)

 def __str__(self):
 return self.amount</code></pre></figure>

So now our category instead of being a regular choices field it is now a model and the <code class="highlighter-rouge">Expense</code> model have a 
relationship with it using a foreign key.

If we create a <code class="highlighter-rouge">ModelForm</code> using this model, the result will be very similar to <a href="#ChoiceField">our first example</a>.

To simulate a grouped categories you will need the code below. First create a new module named fields.py:

fields.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from functools import partial
from itertools import groupby
from operator import attrgetter

from django.forms.models import ModelChoiceIterator, ModelChoiceField


class GroupedModelChoiceIterator(ModelChoiceIterator):
 def __init__(self, field, groupby):
 self.groupby = groupby
 super().__init__(field)

 def __iter__(self):
 if self.field.empty_label is not None:
 yield ("", self.field.empty_label)
 queryset = self.queryset
 # Can't use iterator() when queryset uses prefetch_related()
 if not queryset._prefetch_related_lookups:
 queryset = queryset.iterator()
 for group, objs in groupby(queryset, self.groupby):
 yield (group, [self.choice(obj) for obj in objs])


class GroupedModelChoiceField(ModelChoiceField):
 def __init__(self, *args, choices_groupby, **kwargs):
 if isinstance(choices_groupby, str):
 choices_groupby = attrgetter(choices_groupby)
 elif not callable(choices_groupby):
 raise TypeError('choices_groupby must either be a str or a callable accepting a single argument')
 self.iterator = partial(GroupedModelChoiceIterator, groupby=choices_groupby)
 super().__init__(*args, **kwargs)</code></pre></figure>

And here is how you use it in your forms:

forms.py

<div class="row">
 <div class="eight columns">


<figure class="highlight"><pre><code class="language-python" data-lang="python">from django import forms
from .fields import GroupedModelChoiceField
from .models import Category, Expense

class ExpenseForm(forms.ModelForm):
 category = GroupedModelChoiceField(
 queryset=Category.objects.exclude(parent=None), 
 choices_groupby='parent'
 )

 class Meta:
 model = Expense
 fields = ('amount', 'date', 'category')</code></pre></figure>


 </div>
 <div class="four columns">
 <img src="https://simpleisbetterthancomplex.com/media/2019/01/form3.jpg" alt="Django Grouped ModelChoiceField" style="max-width:100%;" />
 </div>
</div>

Because in the example above I used a self-referencing relationship I had to add the <code class="highlighter-rouge">exclude(parent=None)</code> to hide
the “group categories” from showing up in the select input as a valid option.

<hr />

<h4 id="further-reading">Further Reading</h4>

You can download the code used in this tutorial from GitHub: <a href="https://github.com/sibtc/django-grouped-choice-field-example">github.com/sibtc/django-grouped-choice-field-example</a>

Credits to the solution <a href="https://code.djangoproject.com/ticket/27331#comment:7">Simon Charette on Django Ticket Track</a>.

The Django forms API have two field types to work with multiple options: ChoiceField and ModelChoiceField.
Both use select input as the default widget and they work in a similar way, except that ModelChoiceField is designed 
to handle QuerySets and work with foreign key relationships.
A basic implementation using a ChoiceField would be:
class ExpenseForm(forms.Form):
 CHOICES = (
 (11, 'Credit Card'),
 (12, 'Student Loans'),
 (13, 'Taxes'),
 (21, 'Books'),
 (22, 'Games'),
 (31, 'Groceries'),
 (32, 'Restaurants'),
 )
 amount = forms.DecimalField()
 date = forms.DateField()
 category = forms.ChoiceField(choices=CHOICES)



 
Grouped Choice Field
You can also organize the choices in groups to generate the <optgroup> tags like this:
class ExpenseForm(forms.Form):
 CHOICES = (
 ('Debt', (
 (11, 'Credit Card'),
 (12, 'Student Loans'),
 (13, 'Taxes'),
 )),
 ('Entertainment', (
 (21, 'Books'),
 (22, 'Games'),
 )),
 ('Everyday', (
 (31, 'Groceries'),
 (32, 'Restaurants'),
 )),
 )
 amount = forms.DecimalField()
 date = forms.DateField()
 category = forms.ChoiceField(choices=CHOICES)



 
Grouped Model Choice Field
When you are using a ModelChoiceField unfortunately there is no built-in solution.
Recently I found a nice solution on Django’s ticket tracker, where 
someone proposed adding an opt_group argument to the ModelChoiceField.
While the discussion is still ongoing, Simon Charette proposed
a really good solution.
Let’s see how we can integrate it in our project.
First consider the following models:
models.py
from django.db import models

class Category(models.Model):
 name = models.CharField(max_length=30)
 parent = models.ForeignKey('Category', on_delete=models.CASCADE, null=True)

 def __str__(self):
 return self.name

class Expense(models.Model):
 amount = models.DecimalField(max_digits=10, decimal_places=2)
 date = models.DateField()
 category = models.ForeignKey(Category, on_delete=models.CASCADE)

 def __str__(self):
 return self.amount


So now our category instead of being a regular choices field it is now a model and the Expense model have a 
relationship with it using a foreign key.
If we create a ModelForm using this model, the result will be very similar to our first example.
To simulate a grouped categories you will need the code below. First create a new module named fields.py:
fields.py
from functools import partial
from itertools import groupby
from operator import attrgetter

from django.forms.models import ModelChoiceIterator, ModelChoiceField


class GroupedModelChoiceIterator(ModelChoiceIterator):
 def __init__(self, field, groupby):
 self.groupby = groupby
 super().__init__(field)

 def __iter__(self):
 if self.field.empty_label is not None:
 yield ("", self.field.empty_label)
 queryset = self.queryset
 # Can't use iterator() when queryset uses prefetch_related()
 if not queryset._prefetch_related_lookups:
 queryset = queryset.iterator()
 for group, objs in groupby(queryset, self.groupby):
 yield (group, [self.choice(obj) for obj in objs])


class GroupedModelChoiceField(ModelChoiceField):
 def __init__(self, *args, choices_groupby, **kwargs):
 if isinstance(choices_groupby, str):
 choices_groupby = attrgetter(choices_groupby)
 elif not callable(choices_groupby):
 raise TypeError('choices_groupby must either be a str or a callable accepting a single argument')
 self.iterator = partial(GroupedModelChoiceIterator, groupby=choices_groupby)
 super().__init__(*args, **kwargs)


And here is how you use it in your forms:
forms.py
from django import forms
from .fields import GroupedModelChoiceField
from .models import Category, Expense

class ExpenseForm(forms.ModelForm):
 category = GroupedModelChoiceField(
 queryset=Category.objects.exclude(parent=None), 
 choices_groupby='parent'
 )

 class Meta:
 model = Expense
 fields = ('amount', 'date', 'category')



 
Because in the example above I used a self-referencing relationship I had to add the exclude(parent=None) to hide
the “group categories” from showing up in the select input as a valid option.
Further Reading
You can download the code used in this tutorial from GitHub: github.com/sibtc/django-grouped-choice-field-example
Credits to the solution Simon Charette on Django Ticket Track.

How to Implement Grouped Model Choice Field

JWT stand for JSON Web Token and it is an authentication strategy used by client/server applications where the
client is a Web application using JavaScript and some frontend framework like Angular, React or VueJS.

In this tutorial we are going to explore the specifics of JWT authentication. If you want to learn more about
Token-based authentication using Django REST Framework (DRF), or if you want to know how to start a new DRF project
you can read this tutorial: <a href="/tutorial/2018/11/22/how-to-implement-token-authentication-using-django-rest-framework.html">How to Implement Token Authentication using Django REST Framework</a>.
The concepts are the same, we are just going to switch the authentication backend.

<ul>
 <li><a href="#how-jwt-works">How JWT Works?</a></li>
 <li><a href="#installation--setup">Installation &amp; Setup</a></li>
 <li><a href="#example-code">Example Code</a></li>
 <li><a href="#usage">Usage</a>
 <ul>
 <li><a href="#obtain-token">Obtain Token</a></li>
 <li><a href="#refresh-token">Refresh Token</a></li>
 </ul>
 </li>
 <li><a href="#whats-the-point-of-the-refresh-token">What’s The Point of The Refresh Token?</a></li>
 <li><a href="#further-reading">Further Reading</a></li>
</ul>

<hr />

<h4 id="how-jwt-works">How JWT Works?</h4>

The JWT is just an authorization token that should be included in all requests:

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">curl http://127.0.0.1:8000/hello/ -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQzODI4NDMxLCJqdGkiOiI3ZjU5OTdiNzE1MGQ0NjU3OWRjMmI0OTE2NzA5N2U3YiIsInVzZXJfaWQiOjF9.Ju70kdcaHKn1Qaz8H42zrOYk0Jx9kIckTn9Xx7vhikY'</code></pre></figure>

The JWT is acquired by exchanging an username + password for an access token and an refresh token.

The access token is usually short-lived (expires in 5 min or so, can be customized though).

The refresh token lives a little bit longer (expires in 24 hours, also customizable). It is comparable to an
authentication session. After it expires, you need a full login with username + password again.

Why is that?

It’s a security feature and also it’s because the JWT holds a little bit more information. If you look closely the
example I gave above, you will see the token is composed by three parts:

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">xxxxx.yyyyy.zzzzz</code></pre></figure>

Those are three distinctive parts that compose a JWT:

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">header.payload.signature</code></pre></figure>

So we have here:

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">header = eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
payload = eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQzODI4NDMxLCJqdGkiOiI3ZjU5OTdiNzE1MGQ0NjU3OWRjMmI0OTE2NzA5N2U3YiIsInVzZXJfaWQiOjF9
signature = Ju70kdcaHKn1Qaz8H42zrOYk0Jx9kIckTn9Xx7vhikY</code></pre></figure>

This information is encoded using Base64. If we decode, we will see something like this:

header

<figure class="highlight"><pre><code class="language-json" data-lang="json">{
 "typ": "JWT",
 "alg": "HS256"
}</code></pre></figure>

payload

<figure class="highlight"><pre><code class="language-json" data-lang="json">{
 "token_type": "access",
 "exp": 1543828431,
 "jti": "7f5997b7150d46579dc2b49167097e7b",
 "user_id": 1
}</code></pre></figure>

signature

The signature is issued by the JWT backend, using the header base64 + payload base64 + <code class="highlighter-rouge">SECRET_KEY</code>. Upon each request
this signature is verified. If any information in the header or in the payload was changed by the client it will
invalidate the signature. The only way of checking and validating the signature is by using your application’s
<code class="highlighter-rouge">SECRET_KEY</code>. Among other things, that’s why you should always keep your <code class="highlighter-rouge">SECRET_KEY</code> secret!

<hr />

<h4 id="installation--setup">Installation &amp; Setup</h4>

For this tutorial we are going to use the <a href="https://github.com/davesque/django-rest-framework-simplejwt"><code class="highlighter-rouge">djangorestframework_simplejwt</code></a>
library, recommended by the DRF developers.

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">pip install djangorestframework_simplejwt</code></pre></figure>

settings.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">REST_FRAMEWORK = {
 'DEFAULT_AUTHENTICATION_CLASSES': [
 'rest_framework_simplejwt.authentication.JWTAuthentication',
 ],
}</code></pre></figure>

urls.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from django.urls import path
from rest_framework_simplejwt import views as jwt_views

urlpatterns = [
 # Your URLs...
 path('api/token/', jwt_views.TokenObtainPairView.as_view(), name='token_obtain_pair'),
 path('api/token/refresh/', jwt_views.TokenRefreshView.as_view(), name='token_refresh'),
]</code></pre></figure>

<hr />

<h4 id="example-code">Example Code</h4>

For this tutorial I will use the following route and API view:

views.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.permissions import IsAuthenticated


class HelloView(APIView):
 permission_classes = (IsAuthenticated,)

 def get(self, request):
 content = {'message': 'Hello, World!'}
 return Response(content)</code></pre></figure>

urls.py

<figure class="highlight"><pre><code class="language-python" data-lang="python">from django.urls import path
from myapi.core import views

urlpatterns = [
 path('hello/', views.HelloView.as_view(), name='hello'),
]</code></pre></figure>

<hr />

<h4 id="usage">Usage</h4>

I will be using <a href="https://httpie.org">HTTPie</a> to consume the API endpoints via the terminal. But you can also use
<a href="https://curl.haxx.se/">cURL</a> (readily available in many OS) to try things out locally.

Or alternatively, use the DRF web interface by accessing the endpoint URLs like this:

<img src="https://simpleisbetterthancomplex.com/media/2018/12/drf-web.png" alt="DRF JWT Obtain Token" />

<h5 id="obtain-token">Obtain Token</h5>

First step is to authenticate and obtain the token. The endpoint is <code class="highlighter-rouge">/api/token/</code> and it only accepts POST requests.

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">http post http://127.0.0.1:8000/api/token/ username=vitor password=123</code></pre></figure>

<img src="https://simpleisbetterthancomplex.com/media/2018/12/jwt-obtain-token.png" alt="HTTPie JWT Obtain Token" />

So basically your response body is the two tokens:

<figure class="highlight"><pre><code class="language-json" data-lang="json">{
 "access": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQ1MjI0MjU5LCJqdGkiOiIyYmQ1NjI3MmIzYjI0YjNmOGI1MjJlNThjMzdjMTdlMSIsInVzZXJfaWQiOjF9.D92tTuVi_YcNkJtiLGHtcn6tBcxLCBxz9FKD3qzhUg8",
 "refresh": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTU0NTMxMDM1OSwianRpIjoiMjk2ZDc1ZDA3Nzc2NDE0ZjkxYjhiOTY4MzI4NGRmOTUiLCJ1c2VyX2lkIjoxfQ.rA-mnGRg71NEW_ga0sJoaMODS5ABjE5HnxJDb0F8xAo"
}</code></pre></figure>

After that you are going to store both the access token and the refresh token on the client side, usually in
the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage">localStorage</a>.

In order to access the protected views on the backend (i.e., the API endpoints that require authentication), you should
include the access token in the header of all requests, like this:

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">http http://127.0.0.1:8000/hello/ "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQ1MjI0MjAwLCJqdGkiOiJlMGQxZDY2MjE5ODc0ZTY3OWY0NjM0ZWU2NTQ2YTIwMCIsInVzZXJfaWQiOjF9.9eHat3CvRQYnb5EdcgYFzUyMobXzxlAVh_IAgqyvzCE"</code></pre></figure>

<img src="https://simpleisbetterthancomplex.com/media/2018/12/jwt-bearer.png" alt="HTTPie JWT Hello, World!" />

You can use this access token for the next five minutes.

After five min, the token will expire, and if you try to access the view again, you are going to get the following
error:

<figure class="highlight"><pre><code class="language-bash" data-lang="bash">http http://127.0.0.1:8000/hello/ "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQ1MjI0MjAwLCJqdGkiOiJlMGQxZDY2MjE5ODc0ZTY3OWY0NjM0ZWU2NTQ2YTIwMCIsInVzZXJfaWQiOjF9.9eHat3CvRQYnb5EdcgYFzUyMobXzxlAVh_IAgqyvzCE"</code></pre></figure>

<img src="https://simpleisbetterthancomplex.com/media/2018/12/jwt-expired.png" alt="HTTPie JWT Expired" />

<h5 id="refresh-token">Refresh Token</h5>

To get a new access token, you should use the refresh token endpoint <code class="highlighter-rouge">/api/token/refresh/</code> posting the
refresh token:

<figure class="highlight"><pre><code class="language-python" data-lang="python">http post http://127.0.0.1:8000/api/token/refresh/ refresh=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTU0NTMwODIyMiwianRpIjoiNzAyOGFlNjc0ZTdjNDZlMDlmMzUwYjg3MjU1NGUxODQiLCJ1c2VyX2lkIjoxfQ.Md8AO3dDrQBvWYWeZsd_A1J39z6b6HEwWIUZ7ilOiPE</code></pre></figure>

<img src="https://simpleisbetterthancomplex.com/media/2018/12/jwt-refresh-token.png" alt="HTTPie JWT Refresh Token" />

The return is a new access token that you should use in the subsequent requests.

The refresh token is valid for the next 24 hours. When it finally expires too, the user will need to perform a
full authentication again using their username and password to get a new set of access token + refresh token.

<hr />

<h4 id="whats-the-point-of-the-refresh-token">What’s The Point of The Refresh Token?</h4>

At first glance the refresh token may look pointless, but in fact it is necessary to make sure the user still have
the correct permissions. If your access token have a long expire time, it may take longer to update the information
associated with the token. That’s because the authentication check is done by cryptographic means, instead of querying
the database and verifying the data. So some information is sort of cached.

There is also a security aspect, in a sense that the refresh token only travel in the POST data. And the
access token is sent via HTTP header, which may be logged along the way. So this also give a short window, should
your access token be compromised.

<hr />

<h4 id="further-reading">Further Reading</h4>

This should cover the basics on the backend implementation. It’s worth checking the
<a href="https://github.com/davesque/django-rest-framework-simplejwt">djangorestframework_simplejwt settings</a> for further
customization and to get a better idea of what the library offers.

The implementation on the frontend depends on what framework/library you are using. Some libraries and articles
covering popular frontend frameworks like angular/react/vue.js:

<ul>
 <li><a href="https://github.com/auth0/angular-jwt">Angular JWT library</a></li>
 <li><a href="https://github.com/auth0/angular2-jwt">Angular 2 JWT library</a></li>
 <li><a href="https://auth0.com/blog/secure-your-react-and-redux-app-with-jwt-authentication/">Secure Your React and Redux App with JWT Authentication</a></li>
 <li><a href="https://www.pydanny.com/drf-jwt-axios-vue.html">Authenticating via JWT using Django, Axios, and Vue</a></li>
</ul>

The code used in this tutorial is available at <a href="https://github.com/sibtc/drf-jwt-example">github.com/sibtc/drf-jwt-example</a>.

JWT stand for JSON Web Token and it is an authentication strategy used by client/server applications where the
client is a Web application using JavaScript and some frontend framework like Angular, React or VueJS.
In this tutorial we are going to explore the specifics of JWT authentication. If you want to learn more about
Token-based authentication using Django REST Framework (DRF), or if you want to know how to start a new DRF project
you can read this tutorial: How to Implement Token Authentication using Django REST Framework.
The concepts are the same, we are just going to switch the authentication backend.
How JWT Works?
Installation & Setup
Example Code
Usage
    
Obtain Token
Refresh Token
What’s The Point of The Refresh Token?
Further Reading
How JWT Works?
The JWT is just an authorization token that should be included in all requests:
curl http://127.0.0.1:8000/hello/ -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQzODI4NDMxLCJqdGkiOiI3ZjU5OTdiNzE1MGQ0NjU3OWRjMmI0OTE2NzA5N2U3YiIsInVzZXJfaWQiOjF9.Ju70kdcaHKn1Qaz8H42zrOYk0Jx9kIckTn9Xx7vhikY'


The JWT is acquired by exchanging an username + password for an access token and an refresh token.
The access token is usually short-lived (expires in 5 min or so, can be customized though).
The refresh token lives a little bit longer (expires in 24 hours, also customizable). It is comparable to an
authentication session. After it expires, you need a full login with username + password again.
Why is that?
It’s a security feature and also it’s because the JWT holds a little bit more information. If you look closely the
example I gave above, you will see the token is composed by three parts:
xxxxx.yyyyy.zzzzz


Those are three distinctive parts that compose a JWT:
header.payload.signature


So we have here:
header = eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
payload = eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQzODI4NDMxLCJqdGkiOiI3ZjU5OTdiNzE1MGQ0NjU3OWRjMmI0OTE2NzA5N2U3YiIsInVzZXJfaWQiOjF9
signature = Ju70kdcaHKn1Qaz8H42zrOYk0Jx9kIckTn9Xx7vhikY


This information is encoded using Base64. If we decode, we will see something like this:
header
{
  "typ": "JWT",
  "alg": "HS256"
}


payload
{
  "token_type": "access",
  "exp": 1543828431,
  "jti": "7f5997b7150d46579dc2b49167097e7b",
  "user_id": 1
}


signature
The signature is issued by the JWT backend, using the header base64 + payload base64 + SECRET_KEY. Upon each request
this signature is verified. If any information in the header or in the payload was changed by the client it will
invalidate the signature. The only way of checking and validating the signature is by using your application’s
SECRET_KEY. Among other things, that’s why you should always keep your SECRET_KEY secret!
Installation & Setup
For this tutorial we are going to use the djangorestframework_simplejwt
library, recommended by the DRF developers.
pip install djangorestframework_simplejwt


settings.py
REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ],
}


urls.py
from django.urls import path
from rest_framework_simplejwt import views as jwt_views

urlpatterns = [
    # Your URLs...
    path('api/token/', jwt_views.TokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('api/token/refresh/', jwt_views.TokenRefreshView.as_view(), name='token_refresh'),
]




Example Code
For this tutorial I will use the following route and API view:
views.py
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.permissions import IsAuthenticated


class HelloView(APIView):
    permission_classes = (IsAuthenticated,)

    def get(self, request):
        content = {'message': 'Hello, World!'}
        return Response(content)


urls.py
from django.urls import path
from myapi.core import views

urlpatterns = [
    path('hello/', views.HelloView.as_view(), name='hello'),
]




Usage
I will be using HTTPie to consume the API endpoints via the terminal. But you can also use
cURL (readily available in many OS) to try things out locally.
Or alternatively, use the DRF web interface by accessing the endpoint URLs like this:

Obtain Token
First step is to authenticate and obtain the token. The endpoint is /api/token/ and it only accepts POST requests.
http post http://127.0.0.1:8000/api/token/ username=vitor password=123



So basically your response body is the two tokens:
{
    "access": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQ1MjI0MjU5LCJqdGkiOiIyYmQ1NjI3MmIzYjI0YjNmOGI1MjJlNThjMzdjMTdlMSIsInVzZXJfaWQiOjF9.D92tTuVi_YcNkJtiLGHtcn6tBcxLCBxz9FKD3qzhUg8",
    "refresh": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTU0NTMxMDM1OSwianRpIjoiMjk2ZDc1ZDA3Nzc2NDE0ZjkxYjhiOTY4MzI4NGRmOTUiLCJ1c2VyX2lkIjoxfQ.rA-mnGRg71NEW_ga0sJoaMODS5ABjE5HnxJDb0F8xAo"
}


After that you are going to store both the access token and the refresh token on the client side, usually in
the localStorage.
In order to access the protected views on the backend (i.e., the API endpoints that require authentication), you should
include the access token in the header of all requests, like this:
http http://127.0.0.1:8000/hello/ "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQ1MjI0MjAwLCJqdGkiOiJlMGQxZDY2MjE5ODc0ZTY3OWY0NjM0ZWU2NTQ2YTIwMCIsInVzZXJfaWQiOjF9.9eHat3CvRQYnb5EdcgYFzUyMobXzxlAVh_IAgqyvzCE"



You can use this access token for the next five minutes.
After five min, the token will expire, and if you try to access the view again, you are going to get the following
error:
http http://127.0.0.1:8000/hello/ "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTQ1MjI0MjAwLCJqdGkiOiJlMGQxZDY2MjE5ODc0ZTY3OWY0NjM0ZWU2NTQ2YTIwMCIsInVzZXJfaWQiOjF9.9eHat3CvRQYnb5EdcgYFzUyMobXzxlAVh_IAgqyvzCE"



Refresh Token
To get a new access token, you should use the refresh token endpoint /api/token/refresh/ posting the
refresh token:
http post http://127.0.0.1:8000/api/token/refresh/ refresh=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTU0NTMwODIyMiwianRpIjoiNzAyOGFlNjc0ZTdjNDZlMDlmMzUwYjg3MjU1NGUxODQiLCJ1c2VyX2lkIjoxfQ.Md8AO3dDrQBvWYWeZsd_A1J39z6b6HEwWIUZ7ilOiPE



The return is a new access token that you should use in the subsequent requests.
The refresh token is valid for the next 24 hours. When it finally expires too, the user will need to perform a
full authentication again using their username and password to get a new set of access token + refresh token.
What’s The Point of The Refresh Token?
At first glance the refresh token may look pointless, but in fact it is necessary to make sure the user still have
the correct permissions. If your access token have a long expire time, it may take longer to update the information
associated with the token. That’s because the authentication check is done by cryptographic means, instead of querying
the database and verifying the data. So some information is sort of cached.
There is also a security aspect, in a sense that the refresh token only travel in the POST data. And the
access token is sent via HTTP header, which may be logged along the way. So this also give a short window, should
your access token be compromised.
Further Reading
This should cover the basics on the backend implementation. It’s worth checking the
djangorestframework_simplejwt settings for further
customization and to get a better idea of what the library offers.
The implementation on the frontend depends on what framework/library you are using. Some libraries and articles
covering popular frontend frameworks like angular/react/vue.js:
Angular JWT library
Angular 2 JWT library
Secure Your React and Redux App with JWT Authentication
Authenticating via JWT using Django, Axios, and Vue
The code used in this tutorial is available at github.com/sibtc/drf-jwt-example.

How to Use JWT Authentication with Django REST Framework

[Django 2.1.3 / Python 3.6.5 / Bootstrap 4.1.3]
In this tutorial we are going to explore some of the Django Crispy Forms features to handle advanced/custom forms
rendering. This blog post started as a discussion in our community forum,
so I decided to compile the insights and solutions in a blog post to benefit a wider audience.
Table of Contents
Introduction
Installation
Basic Form Rendering
Basic Crispy Form Rendering
Custom Fields Placement with Crispy Forms
Crispy Forms Layout Helpers
Custom Crispy Field
Conclusions
Introduction
Throughout this tutorial we are going to implement the following Bootstrap 4 form using Django APIs:

This was taken from Bootstrap 4 official documentation
as an example of how to use form rows.
NOTE!
The examples below refer to a base.html template. Consider the code below:
base.html
<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
 <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.1.3/css/bootstrap.min.css" integrity="sha384-MCw98/SFnGE8fJT3GXwEOngsV7Zt27NXFoaoApmYm81iuXoPkFOJwJ8ERdknLPMO" crossorigin="anonymous">
</head>
<body>
 <div class="container">
 {% block content %}
 {% endblock %}
 </div>
</body>
</html>




Installation
Install it using pip:
pip install django-crispy-forms


Add it to your INSTALLED_APPS and select which styles to use:
settings.py
INSTALLED_APPS = [
 ...

 'crispy_forms',
]

CRISPY_TEMPLATE_PACK = 'bootstrap4'


For detailed instructions about how to install django-crispy-forms, please refer to this tutorial:
How to Use Bootstrap 4 Forms With Django
Basic Form Rendering
The Python code required to represent the form above is the following:
from django import forms

STATES = (
 ('', 'Choose...'),
 ('MG', 'Minas Gerais'),
 ('SP', 'Sao Paulo'),
 ('RJ', 'Rio de Janeiro')
)

class AddressForm(forms.Form):
 email = forms.CharField(widget=forms.TextInput(attrs={'placeholder': 'Email'}))
 password = forms.CharField(widget=forms.PasswordInput())
 address_1 = forms.CharField(
 label='Address',
 widget=forms.TextInput(attrs={'placeholder': '1234 Main St'})
 )
 address_2 = forms.CharField(
 widget=forms.TextInput(attrs={'placeholder': 'Apartment, studio, or floor'})
 )
 city = forms.CharField()
 state = forms.ChoiceField(choices=STATES)
 zip_code = forms.CharField(label='Zip')
 check_me_out = forms.BooleanField(required=False)


In this case I’m using a regular Form, but it could also be a ModelForm based on a Django model with similar
fields. The state field and the STATES choices could be either a foreign key or anything else. Here I’m just using
a simple static example with three Brazilian states.
Template:
{% extends 'base.html' %}

{% block content %}
 <form method="post">
 {% csrf_token %}
 <table>{{ form.as_table }}</table>
 <button type="submit">Sign in</button>
 </form>
{% endblock %}


Rendered HTML:

Rendered HTML with validation state:

Basic Crispy Form Rendering
Same form code as in the example before.
Template:
{% extends 'base.html' %}

{% load crispy_forms_tags %}

{% block content %}
 <form method="post">
 {% csrf_token %}
 {{ form|crispy }}
 <button type="submit" class="btn btn-primary">Sign in</button>
 </form>
{% endblock %}


Rendered HTML:

Rendered HTML with validation state:

Custom Fields Placement with Crispy Forms
Same form code as in the first example.
Template:
{% extends 'base.html' %}

{% load crispy_forms_tags %}

{% block content %}
 <form method="post">
 {% csrf_token %}
 <div class="form-row">
 <div class="form-group col-md-6 mb-0">
 {{ form.email|as_crispy_field }}
 </div>
 <div class="form-group col-md-6 mb-0">
 {{ form.password|as_crispy_field }}
 </div>
 </div>
 {{ form.address_1|as_crispy_field }}
 {{ form.address_2|as_crispy_field }}
 <div class="form-row">
 <div class="form-group col-md-6 mb-0">
 {{ form.city|as_crispy_field }}
 </div>
 <div class="form-group col-md-4 mb-0">
 {{ form.state|as_crispy_field }}
 </div>
 <div class="form-group col-md-2 mb-0">
 {{ form.zip_code|as_crispy_field }}
 </div>
 </div>
 {{ form.check_me_out|as_crispy_field }}
 <button type="submit" class="btn btn-primary">Sign in</button>
 </form>
{% endblock %}


Rendered HTML:

Rendered HTML with validation state:

Crispy Forms Layout Helpers
We could use the crispy forms layout helpers to achieve the same result as above. The implementation is done inside
the form __init__ method:
forms.py
from django import forms
from crispy_forms.helper import FormHelper
from crispy_forms.layout import Layout, Submit, Row, Column

STATES = (
 ('', 'Choose...'),
 ('MG', 'Minas Gerais'),
 ('SP', 'Sao Paulo'),
 ('RJ', 'Rio de Janeiro')
)

class AddressForm(forms.Form):
 email = forms.CharField(widget=forms.TextInput(attrs={'placeholder': 'Email'}))
 password = forms.CharField(widget=forms.PasswordInput())
 address_1 = forms.CharField(
 label='Address',
 widget=forms.TextInput(attrs={'placeholder': '1234 Main St'})
 )
 address_2 = forms.CharField(
 widget=forms.TextInput(attrs={'placeholder': 'Apartment, studio, or floor'})
 )
 city = forms.CharField()
 state = forms.ChoiceField(choices=STATES)
 zip_code = forms.CharField(label='Zip')
 check_me_out = forms.BooleanField(required=False)

 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 self.helper = FormHelper()
 self.helper.layout = Layout(
 Row(
 Column('email', css_class='form-group col-md-6 mb-0'),
 Column('password', css_class='form-group col-md-6 mb-0'),
 css_class='form-row'
 ),
 'address_1',
 'address_2',
 Row(
 Column('city', css_class='form-group col-md-6 mb-0'),
 Column('state', css_class='form-group col-md-4 mb-0'),
 Column('zip_code', css_class='form-group col-md-2 mb-0'),
 css_class='form-row'
 ),
 'check_me_out',
 Submit('submit', 'Sign in')
 )


The template implementation is very minimal:
{% extends 'base.html' %}

{% load crispy_forms_tags %}

{% block content %}
 {% crispy form %}
{% endblock %}


The end result is the same.
Rendered HTML:

Rendered HTML with validation state:

Custom Crispy Field
You may also customize the field template and easily reuse throughout your application. Let’s say we want to use the
custom Bootstrap 4 checkbox:

From the official documentation, the necessary HTML to output the input above:
<div class="custom-control custom-checkbox">
 <input type="checkbox" class="custom-control-input" id="customCheck1">
 <label class="custom-control-label" for="customCheck1">Check this custom checkbox</label>
</div>


Using the crispy forms API, we can create a new template for this custom field in our “templates” folder:
custom_checkbox.html
{% load crispy_forms_field %}

<div class="form-group">
 <div class="custom-control custom-checkbox">
 {% crispy_field field 'class' 'custom-control-input' %}
 <label class="custom-control-label" for="{{ field.id_for_label }}">{{ field.label }}</label>
 </div>
</div>


Now we can create a new crispy field, either in our forms.py module or in a new Python module named fields.py
or something.
forms.py
from crispy_forms.layout import Field

class CustomCheckbox(Field):
 template = 'custom_checkbox.html'


We can use it now in our form definition:
forms.py
class CustomFieldForm(AddressForm):
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 self.helper = FormHelper()
 self.helper.layout = Layout(
 Row(
 Column('email', css_class='form-group col-md-6 mb-0'),
 Column('password', css_class='form-group col-md-6 mb-0'),
 css_class='form-row'
 ),
 'address_1',
 'address_2',
 Row(
 Column('city', css_class='form-group col-md-6 mb-0'),
 Column('state', css_class='form-group col-md-4 mb-0'),
 Column('zip_code', css_class='form-group col-md-2 mb-0'),
 css_class='form-row'
 ),
 CustomCheckbox('check_me_out'), # <-- Here
 Submit('submit', 'Sign in')
 )


(PS: the AddressForm was defined here and is the same as in the previous example.)
The end result:

Conclusions
There is much more Django Crispy Forms can do. Hopefully this tutorial gave you some extra insights on how to use the
form helpers and layout classes. As always, the official documentation is the best source of information:
Django Crispy Forms layouts docs
Also, the code used in this tutorial is available on GitHub at github.com/sibtc/advanced-crispy-forms-examples.

Advanced Form Rendering with Django Crispy Forms

In this tutorial you are going to learn how to implement Token-based authentication using Django REST Framework (DRF).
The token authentication works by exchanging username and password for a token that will be used in all subsequent
requests so to identify the user on the server side.
The specifics of how the authentication is handled on the client side vary a lot depending on the
technology/language/framework you are working with. The client could be a mobile application using iOS or Android.
It could be a desktop application using Python or C++. It could be a Web application using PHP or Ruby.
But once you understand the overall process, it’s easier to find the necessary resources and documentation for your
specific use case.
Token authentication is suitable for client-server applications, where the token is safely stored. You should never
expose your token, as it would be (sort of) equivalent of a handing out your username and password.
Table of Contents
Setting Up The REST API Project (If you already know how to start a DRF project you can skip this)
Implementing the Token Authentication
User Requesting a Token
Conclusions
Setting Up The REST API Project
So let’s start from the very beginning. Install Django and DRF:
pip install django
pip install djangorestframework


Create a new Django project:
django-admin.py startproject myapi .


Navigate to the myapi folder:
cd myapi


Start a new app. I will call my app core:
django-admin.py startapp core


Here is what your project structure should look like:
myapi/
 |-- core/
 | |-- migrations/
 | |-- __init__.py
 | |-- admin.py
 | |-- apps.py
 | |-- models.py
 | |-- tests.py
 | +-- views.py
 |-- __init__.py
 |-- settings.py
 |-- urls.py
 +-- wsgi.py
manage.py


Add the core app (you created) and the rest_framework app (you installed) to the INSTALLED_APPS, inside the
settings.py module:
myapi/settings.py
INSTALLED_APPS = [
 # Django Apps
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',

 # Third-Party Apps
 'rest_framework',

 # Local Apps (Your project's apps)
 'myapi.core',
]


Return to the project root (the folder where the manage.py script is), and migrate the database:
python manage.py migrate


Let’s create our first API view just to test things out:
myapi/core/views.py
from rest_framework.views import APIView
from rest_framework.response import Response

class HelloView(APIView):
 def get(self, request):
 content = {'message': 'Hello, World!'}
 return Response(content)


Now register a path in the urls.py module:
myapi/urls.py
from django.urls import path
from myapi.core import views

urlpatterns = [
 path('hello/', views.HelloView.as_view(), name='hello'),
]


So now we have an API with just one endpoint /hello/ that we can perform GET requests. We can use the browser to
consume this endpoint, just by accessing the URL http://127.0.0.1:8000/hello/:

We can also ask to receive the response as plain JSON data by passing the format parameter in the querystring like
http://127.0.0.1:8000/hello/?format=json:

Both methods are fine to try out a DRF API, but sometimes a command line tool is more handy as we can play more easily
with the requests headers. You can use cURL, which is widely available on all major
Linux/macOS distributions:
curl http://127.0.0.1:8000/hello/



But usually I prefer to use HTTPie, which is a pretty awesome Python command line tool:
http http://127.0.0.1:8000/hello/



Now let’s protect this API endpoint so we can implement the token authentication:
myapi/core/views.py
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.permissions import IsAuthenticated # <-- Here


class HelloView(APIView):
 permission_classes = (IsAuthenticated,) # <-- And here

 def get(self, request):
 content = {'message': 'Hello, World!'}
 return Response(content)


Try again to access the API endpoint:
http http://127.0.0.1:8000/hello/



And now we get an HTTP 403 Forbidden error. Now let’s implement the token authentication so we can access this
endpoint.
Implementing the Token Authentication
We need to add two pieces of information in our settings.py module. First include rest_framework.authtoken to
your INSTALLED_APPS and include the TokenAuthentication to REST_FRAMEWORK:
myapi/settings.py
INSTALLED_APPS = [
 # Django Apps
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',

 # Third-Party Apps
 'rest_framework',
 'rest_framework.authtoken', # <-- Here

 # Local Apps (Your project's apps)
 'myapi.core',
]

REST_FRAMEWORK = {
 'DEFAULT_AUTHENTICATION_CLASSES': [
 'rest_framework.authentication.TokenAuthentication', # <-- And here
 ],
}


Migrate the database to create the table that will store the authentication tokens:
python manage.py migrate



Now we need a user account. Let’s just create one using the manage.py command line utility:
python manage.py createsuperuser --username vitor --email vitor@example.com


The easiest way to generate a token, just for testing purpose, is using the command line utility again:
python manage.py drf_create_token vitor



This piece of information, the random string 9054f7aa9305e012b3c2300408c3dfdf390fcddf is what we are going to use
next to authenticate.
But now that we have the TokenAuthentication in place, let’s try to make another request to our /hello/ endpoint:
http http://127.0.0.1:8000/hello/



Notice how our API is now providing some extra information to the client on the required authentication method.
So finally, let’s use our token!
http http://127.0.0.1:8000/hello/ 'Authorization: Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf'



And that’s pretty much it. For now on, on all subsequent request you should include the header Authorization: Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf.
The formatting looks weird and usually it is a point of confusion on how to set this header. It will depend on the
client and how to set the HTTP request header.
For example, if we were using cURL, the command would be something like this:
curl http://127.0.0.1:8000/hello/ -H 'Authorization: Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf'


Or if it was a Python requests call:
import requests

url = 'http://127.0.0.1:8000/hello/'
headers = {'Authorization': 'Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf'}
r = requests.get(url, headers=headers)


Or if we were using Angular, you could implement an HttpInterceptor and set a header:
import { Injectable } from '@angular/core';
import { HttpRequest, HttpHandler, HttpEvent, HttpInterceptor } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable()
export class AuthInterceptor implements HttpInterceptor {
 intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
 const user = JSON.parse(localStorage.getItem('user'));
 if (user && user.token) {
 request = request.clone({
 setHeaders: {
 Authorization: `Token ${user.accessToken}`
 }
 });
 }
 return next.handle(request);
 }
}




User Requesting a Token
The DRF provide an endpoint for the users to request an authentication token using their username and password.
Include the following route to the urls.py module:
myapi/urls.py
from django.urls import path
from rest_framework.authtoken.views import obtain_auth_token # <-- Here
from myapi.core import views

urlpatterns = [
 path('hello/', views.HelloView.as_view(), name='hello'),
 path('api-token-auth/', obtain_auth_token, name='api_token_auth'), # <-- And here
]


So now we have a brand new API endpoint, which is /api-token-auth/. Let’s first inspect it:
http http://127.0.0.1:8000/api-token-auth/



It doesn’t handle GET requests. Basically it’s just a view to receive a POST request with username and password.
Let’s try again:
http post http://127.0.0.1:8000/api-token-auth/ username=vitor password=123



The response body is the token associated with this particular user. After this point you store this token and apply
it to the future requests.
Then, again, the way you are going to make the POST request to the API depends on the language/framework you are using.
If this was an Angular client, you could store the token in the localStorage, if this was a Desktop CLI application
you could store in a text file in the user’s home directory in a dot file.
Conclusions
Hopefully this tutorial provided some insights on how the token authentication works. I will try to follow up this
tutorial providing some concrete examples of Angular applications, command line applications and Web clients as well.
It is important to note that the default Token implementation has some limitations such as only one token per user, no
built-in way to set an expiry date to the token.
You can grab the code used in this tutorial at github.com/sibtc/drf-token-auth-example.

How to Implement Token Authentication using Django REST Framework

<div class="info">
 Updated at Nov 8, 2018:
 New video added to the series: How to integrate Django forms with Bootstrap 4.
</div>

In this tutorial series, we are going to explore Django’s authentication system by implementing sign up, login, logout,
password change, password reset and protected views from non-authenticated users. This tutorial is organized in 8
videos, one for each topic, ranging from 4 min to 15 min each.

<ul>
 <li><a href="#setup">Setup</a></li>
 <li><a href="#sign-up">Sign Up</a></li>
 <li><a href="#login">Login</a></li>
 <li><a href="#logout">Logout</a></li>
 <li><a href="#password-change">Password Change</a></li>
 <li><a href="#password-reset">Password Reset</a></li>
 <li><a href="#protecting-views">Protecting Views</a></li>
 <li><a href="#bootstrap-4-forms">Bootstrap 4 Forms (Extra)</a></li>
 <li><a href="#conclusions">Conclusions</a></li>
</ul>

<hr />

<h4 id="setup">Setup</h4>

Starting a Django project from scratch, creating a virtual environment and an initial Django app. After that, we are
going to setup the templates and create an initial view to start working on the authentication.

If you are already familiar with Django, you can skip this video and jump to the <a href="#sign-up">Sign Up</a> tutorial below.

<iframe width="560" height="315" src="https://www.youtube.com/embed/60GTvKCuam8" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="sign-up">Sign Up</h4>

First thing we are going to do is implement a sign up view using the built-in <code class="highlighter-rouge">UserCreationForm</code>. In this video you
are also going to get some insights on basic Django form processing.

<iframe width="560" height="315" src="https://www.youtube.com/embed/9-ALutreCkE" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="login">Login</h4>

In this video tutorial we are going to first include the built-in Django auth URLs to our project and proceed to
implement the login view.

<iframe width="560" height="315" src="https://www.youtube.com/embed/R8yjsg0TlCI" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="logout">Logout</h4>

In this tutorial we are going to include Django logout and also start playing with conditional templates, displaying
different content depending if the user is authenticated or not.

<iframe width="560" height="315" src="https://www.youtube.com/embed/UtasCG2Eb7o" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="password-change">Password Change</h4>

Next The password change is a view where an authenticated user can change their password.

<iframe width="560" height="315" src="https://www.youtube.com/embed/mJkwKsSnWXo" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="password-reset">Password Reset</h4>

This tutorial is perhaps the most complicated one, because it involves several views and also sending emails. In this
video tutorial you are going to learn how to use the default implementation of the password reset process and how to
change the email messages.

<iframe width="560" height="315" src="https://www.youtube.com/embed/JBhpo0o1Ajg" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="protecting-views">Protecting Views</h4>

After implementing the whole authentication system, this video gives you an overview on how to protect some views from
non authenticated users by using the <code class="highlighter-rouge">@login_required</code> decorator and also using class-based views mixins.

<iframe width="560" height="315" src="https://www.youtube.com/embed/o0nvMYxBpRo" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="bootstrap-4-forms">Bootstrap 4 Forms</h4>

Extra video showing how to integrate Django with Bootstrap 4 and how to use Django Crispy Forms to render Bootstrap
forms properly. This video also include some general advices and tips about using Bootstrap 4.

<iframe width="560" height="315" src="https://www.youtube.com/embed/Sy8dVjJqLHI" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<hr />

<h4 id="conclusions">Conclusions</h4>

If you want to learn more about Django authentication and some extra stuff related to it, like how to use Bootstrap
to make your auth forms look good, or how to write unit tests for your auth-related views, you can read the forth part
of my beginners guide to Django: <a href="/series/2017/09/25/a-complete-beginners-guide-to-django-part-4.html">A Complete Beginner’s Guide to Django - Part 4 - Authentication</a>.

Of course the official documentation is the best source of information: <a href="https://docs.djangoproject.com/en/2.1/topics/auth/default/">Using the Django authentication system</a>

The code used in this tutorial: <a href="https://github.com/sibtc/django-auth-tutorial-example">github.com/sibtc/django-auth-tutorial-example</a>

This was my first time recording this kind of content, so your feedback is highly appreciated. Please let me know what
you think!

And don’t forget to <a href="https://www.youtube.com/channel/UCS3lgmo8xYcOGTn_fv2mLgw?sub_confirmation=1">subscribe to my YouTube channel!</a>
I will post exclusive Django tutorials there. So stay tuned! :-)

Updated at Nov 8, 2018:
  New video added to the series: How to integrate Django forms with Bootstrap 4.


In this tutorial series, we are going to explore Django’s authentication system by implementing sign up, login, logout,
password change, password reset and protected views from non-authenticated users. This tutorial is organized in 8
videos, one for each topic, ranging from 4 min to 15 min each.
Setup
Sign Up
Login
Logout
Password Change
Password Reset
Protecting Views
Bootstrap 4 Forms (Extra)
Conclusions
Setup
Starting a Django project from scratch, creating a virtual environment and an initial Django app. After that, we are
going to setup the templates and create an initial view to start working on the authentication.
If you are already familiar with Django, you can skip this video and jump to the Sign Up tutorial below.




Sign Up
First thing we are going to do is implement a sign up view using the built-in UserCreationForm. In this video you
are also going to get some insights on basic Django form processing.




Login
In this video tutorial we are going to first include the built-in Django auth URLs to our project and proceed to
implement the login view.




Logout
In this tutorial we are going to include Django logout and also start playing with conditional templates, displaying
different content depending if the user is authenticated or not.




Password Change
Next The password change is a view where an authenticated user can change their password.




Password Reset
This tutorial is perhaps the most complicated one, because it involves several views and also sending emails. In this
video tutorial you are going to learn how to use the default implementation of the password reset process and how to
change the email messages.




Protecting Views
After implementing the whole authentication system, this video gives you an overview on how to protect some views from
non authenticated users by using the @login_required decorator and also using class-based views mixins.




Bootstrap 4 Forms
Extra video showing how to integrate Django with Bootstrap 4 and how to use Django Crispy Forms to render Bootstrap
forms properly. This video also include some general advices and tips about using Bootstrap 4.




Conclusions
If you want to learn more about Django authentication and some extra stuff related to it, like how to use Bootstrap
to make your auth forms look good, or how to write unit tests for your auth-related views, you can read the forth part
of my beginners guide to Django: A Complete Beginner’s Guide to Django - Part 4 - Authentication.
Of course the official documentation is the best source of information: Using the Django authentication system
The code used in this tutorial: github.com/sibtc/django-auth-tutorial-example
This was my first time recording this kind of content, so your feedback is highly appreciated. Please let me know what
you think!
And don’t forget to subscribe to my YouTube channel!
I will post exclusive Django tutorials there. So stay tuned! :-)

Django Authentication Video Tutorial

It's weekend and after a very busy week i am back in my home desk and navigating through my checklist. Though i had not put any priority on my checklist, my eye went to A Simple Django version for beginners. Frankly i forgot what was my real idea ove...

It's weekend and after a very busy week i am back in my home desk and navigating through my checklist. Though i had not put any priority on my checklist, my eye went to <code>A Simple Django version for beginners</code>. Frankly i forgot what was my real idea over it, but i know few of them
<ol>
<li>Running Django inside a single file
</li>
<li>Simple file and folder structure
</li>
</ol>
<h1 id="heading-running-django-inside-a-single-file">Running Django Inside a Single File</h1>
I came up with my own solution from my stackoverflow answers. See Screenshot below.
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1716061430465/99e8f4c8-8602-4e7f-8a9c-f789680d39d9.png" alt class="image--center mx-auto" />
Reference: <a target="_blank" href="https://stackoverflow.com/a/59356081/7587197">https://stackoverflow.com/a/59356081/7587197</a>
So looks like Django in a single file is possible. Here, your views and URLs are inside this same file, but we face problem when dealing with models inside this file since Django works on <code>App concept</code> and has its own guidelines on implementing apps like creating <code>apps.py</code> <code>models.py</code> <code>migrations package</code> and so on
so now let's try to make it more readable and usable.
<h1 id="heading-simple-file-and-folder-structure">Simple file and folder structure</h1>
So, continuing from the single file solution, lets create couple of files to make the code readable. (I am assuming the root folder is <code>mdj</code>) so this means every files will stay inside it.
<ol>
<li><code>urls.py</code>
<pre><code class="lang-python"> urlpatterns = []
</code></pre>
</li>
<li><code>views.py</code> (empty file for now)
</li>
<li><code>manage.py</code> (The main entry file)
<pre><code class="lang-python"> import sys

 SETTINGS = dict(
 SECRET_KEY='djangoISsoCOOL',
 DEBUG=True,
 ROOT_URLCONF='urls', # so that it can denote urls.py
 INSTALLED_APPS=[],

 )
 if __name__ == "__main__":
 import django
 from django.conf import settings
 from django.core.management import execute_from_command_line

 settings.configure(**SETTINGS)
 django.setup()

 execute_from_command_line(sys.argv)
</code></pre>
 lets run this with command <code>python manage.py runserver</code> and it works. Now, lets create a simple page to check if view and urls works.
</li>
</ol>
<pre><code class="lang-python"># views.py
from django.http import HttpResponse

def index(request):
 return HttpResponse("Hello, world.")
</code></pre>
<pre><code class="lang-python"># urls.py
from django.urls import path

import views # import the view
# Todo for you : try with other import style as well

urlpatterns = [
 path('', views.index),
]
</code></pre>
Now, run the server again using <code>python manage.py runserver</code> and it works.
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1716065180214/5b7afc54-a6b8-4da1-b8b1-c6b309952cfa.png" alt class="image--center mx-auto" />
Now, let's make the model and database to work, but we will need to configure app for this, so create few files to configure
<ol>
<li><code>apps.py</code>
<pre><code class="lang-python"> from django.apps import AppConfig

 # just a random name, MDJ=mini django
 class MDJConfig(AppConfig):
 name = 'mdj' # name of the root folder
</code></pre>
</li>
<li><code>models.py</code>
</li>
<li><code>migrations package</code> (<code>migrations</code> folder and an empty <code>__init__.py</code> file)
</li>
</ol>
and register this apps config location on settings(<code>manage.py file</code>), <code>INSTALLED_APPS</code> as
<pre><code class="lang-python"># manage.py
SETTINGS = dict(
 ...
 INSTALLED_APPS=[
 'apps.MDJConfig',
 ],
 ...
)
</code></pre>
Now, lets run the server using, and it did not work this time and we see the error as <code>ModuleNotFoundError: No module named 'mdj'</code> this means, the module, which we assumed to be the root of our project, is not being recognized. So, lets add out <code>root folder path</code> into <code>systems path</code> so that it can be recognized.
Add these following in the <code>manage.py</code> file
<pre><code class="lang-python">import sys
from pathlib import Path

# BASE_DIR = parent of manage.py file
BASE_DIR = Path(__file__).resolve().parent 

# this line will do the magic
sys.path.append(str(BASE_DIR.parent))
</code></pre>
And now, run the server, and it works.
now let's create our very first sample model
<pre><code class="lang-python"># models.py
from django.db import models

class Sample(models.Model):
 name = models.CharField(max_length=100)
</code></pre>
Create migrations using command: <code>python manage.py makemigrations</code> and it works, the migration is created and placed under <code>migrations folder</code>
Now, before applying migrations, configure database (<code>sqlite3 for demo</code>)
<pre><code class="lang-python"># manage.py
SETTINGS = dict(
 ...
 DATABASES={
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': BASE_DIR / 'db.sqlite3',
 }
 }
 ...
)
</code></pre>
and apply migrations using command <code>python manage.py migrate</code> and everything works, the database is created and the migrations are reflected in the database.
Open up Django shell using command <code>python manage.py shell</code> to play with the model.
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1716067810228/d7ebccd6-25a3-4061-96b2-0ceaf46d46f9.png" alt class="image--center mx-auto" />
So, the final structure of the project will look like this,
<ul>
<li>manage.py (core entry point contains settings as well)
</li>
<li>urls.py (all urls for the project)
</li>
<li>views.py (all view functions and classes for the project)
</li>
<li>apps.py (app level configurations)
</li>
<li>models.py (the model file which contains db related works)
</li>
<li>migrations/__init__.py (<code>migrations</code> folder and the empty <code>__init__.py</code> file to store migrations when <code>python manage.py makemigrations</code> command is used)
</li>
</ul>
The final <code>manage.py</code> looks like this
<pre><code class="lang-python">import sys
from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent
sys.path.append(str(BASE_DIR.parent))

SETTINGS = dict(
 BASE_DIR=BASE_DIR,
 SECRET_KEY='djangoISsoCOOL',
 DEBUG=True,
 ROOT_URLCONF='urls', # so that it can denote urls.py
 INSTALLED_APPS=[
 'apps.MDJConfig',
 ],
 DATABASES={
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': BASE_DIR / 'db.sqlite3',
 }
 }
)
if __name__ == "__main__":
 import django
 from django.conf import settings
 from django.core.management import execute_from_command_line

 settings.configure(**SETTINGS)
 django.setup()

 execute_from_command_line(sys.argv)
</code></pre>
<h1 id="heading-what-next">What next ?</h1>
<ol>
<li>Change <code>models</code> to <code>database</code> which can be done by changing <code>MODELS_MODULE_NAME</code> on <code>django/apps/config.py:10</code> Doing this, the app will now know it needs to load models from <code>database.py</code> file instead of <code>models.py</code>
</li>
<li>Changing <code>migrations</code> to <code>databasehistory.</code> To make this work series of changes needs to be done on <code>django.core.management.commands.makemigrations.py</code> file and <code>django.db.migrations.writer.MigrationWriter</code>. I still need to verify doing this myself, since i see lots of things are changed on Django core itself.
</li>
<li>default app name should not be appended when creating table name for models. To make this work, changes are required on <code>django.db.models.options.Options.contribute_to_class</code> to not add <code>app_label</code> if <code>db_table</code> for model is not given
</li>
<li>When (3) is fixed, root folder name can be changed to any without any problems. currently, root folder name is <code>mdj</code> which is hardcoded on some of the files
</li>
<li>When performing all this fixes, create fix and patch it in runtime through <code>manage.py</code> file
</li>
</ol>
Find complete code at: <a target="_blank" href="https://github.com/shrawanx/mdj">https://github.com/shrawanx/mdj</a>
<h3 id="heading-at-the-end-i-feel-this-current-implementation-has-lots-and-lots-of-works-to-do-before-i-can-say-what-the-title-of-this-article-says-but-it-was-fun-trying-and-experimenting-happy-weekend">At the end, i feel this current implementation has lots and lots of works to do before i can say what the title of this article says, but it was fun trying and experimenting. Happy weekend</h3>

It's weekend and after a very busy week i am back in my home desk and navigating through my checklist. Though i had not put any priority on my checklist, my eye went to A Simple Django version for beginners. Frankly i forgot what was my real idea over it, but i know few of them
Running Django inside a single file
Simple file and folder structure
Running Django Inside a Single File
I came up with my own solution from my stackoverflow answers. See Screenshot below.

Reference: https://stackoverflow.com/a/59356081/7587197
So looks like Django in a single file is possible. Here, your views and URLs are inside this same file, but we face problem when dealing with models inside this file since Django works on App concept and has its own guidelines on implementing apps like creating apps.py models.py migrations package and so on
so now let's try to make it more readable and usable.
Simple file and folder structure
So, continuing from the single file solution, lets create couple of files to make the code readable. (I am assuming the root folder is mdj) so this means every files will stay inside it.
urls.py
 urlpatterns = []

views.py (empty file for now)
manage.py (The main entry file)
 import sys

 SETTINGS = dict(
     SECRET_KEY='djangoISsoCOOL',
     DEBUG=True,
     ROOT_URLCONF='urls',  # so that it can denote urls.py
     INSTALLED_APPS=[],

 )
 if __name__ == "__main__":
     import django
     from django.conf import settings
     from django.core.management import execute_from_command_line

     settings.configure(**SETTINGS)
     django.setup()

     execute_from_command_line(sys.argv)

 lets run this with command python manage.py runserver and it works. Now, lets create a simple page to check if view and urls works.
# views.py
from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world.")

# urls.py
from django.urls import path

import views # import the view
# Todo for you : try with other import style as well

urlpatterns = [
    path('', views.index),
]

Now, run the server again using python manage.py runserver and it works.

Now, let's make the model and database to work, but we will need to configure app for this, so create few files to configure
apps.py
 from django.apps import AppConfig

 # just a random name, MDJ=mini django
 class MDJConfig(AppConfig):
     name = 'mdj' # name of the root folder

models.py
migrations package (migrations folder and an empty __init__.py file)
and register this apps config location on settings(manage.py file), INSTALLED_APPS as
# manage.py
SETTINGS = dict(
    ...
    INSTALLED_APPS=[
         'apps.MDJConfig',
    ],
    ...
)

Now, lets run the server using, and it did not work this time and we see the error as ModuleNotFoundError: No module named 'mdj'
this means, the module, which we assumed to be the root of our project, is not being recognized. So, lets add out root folder path into systems path so that it can be recognized.
Add these following in the manage.py file
import sys
from pathlib import Path

# BASE_DIR = parent of manage.py file
BASE_DIR = Path(__file__).resolve().parent 

# this line will do the magic
sys.path.append(str(BASE_DIR.parent))

And now, run the server, and it works.
now let's create our very first sample model
# models.py
from django.db import models

class Sample(models.Model):
    name = models.CharField(max_length=100)

Create migrations using command: python manage.py makemigrations and it works, the migration is created and placed under migrations folder
Now, before applying migrations, configure database (sqlite3 for demo)
# manage.py
SETTINGS = dict(
    ...
    DATABASES={
        'default': {
            'ENGINE': 'django.db.backends.sqlite3',
            'NAME': BASE_DIR / 'db.sqlite3',
        }
    }
    ...
)

and apply migrations using command python manage.py migrate and everything works, the database is created and the migrations are reflected in the database.
Open up Django shell using command python manage.py shell to play with the model.

So, the final structure of the project will look like this,
manage.py (core entry point contains settings as well)
urls.py (all urls for the project)
views.py (all view functions and classes for the project)
apps.py (app level configurations)
models.py (the model file which contains db related works)
migrations/__init__.py (migrations folder and the empty __init__.py file to store migrations when python manage.py makemigrations command is used)
The final manage.py looks like this
import sys
from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent
sys.path.append(str(BASE_DIR.parent))

SETTINGS = dict(
    BASE_DIR=BASE_DIR,
    SECRET_KEY='djangoISsoCOOL',
    DEBUG=True,
    ROOT_URLCONF='urls',  # so that it can denote urls.py
    INSTALLED_APPS=[
        'apps.MDJConfig',
    ],
    DATABASES={
        'default': {
            'ENGINE': 'django.db.backends.sqlite3',
            'NAME': BASE_DIR / 'db.sqlite3',
        }
    }
)
if __name__ == "__main__":
    import django
    from django.conf import settings
    from django.core.management import execute_from_command_line

    settings.configure(**SETTINGS)
    django.setup()

    execute_from_command_line(sys.argv)

What next ?
Change models to database which can be done by changing MODELS_MODULE_NAME on django/apps/config.py:10 Doing this, the app will now know it needs to load models from database.py file instead of models.py
Changing migrations to databasehistory. To make this work series of changes needs to be done on django.core.management.commands.makemigrations.py file and django.db.migrations.writer.MigrationWriter. I still need to verify doing this myself, since i see lots of things are changed on Django core itself.
default app name should not be appended when creating table name for models. To make this work, changes are required on django.db.models.options.Options.contribute_to_class to not add app_label if db_table for model is not given
When (3) is fixed, root folder name can be changed to any without any problems. currently, root folder name is mdj which is hardcoded on some of the files
When performing all this fixes, create fix and patch it in runtime through manage.py file
Find complete code at: https://github.com/shrawanx/mdj
At the end, i feel this current implementation has lots and lots of works to do before i can say what the title of this article says, but it was fun trying and experimenting. Happy weekend

Django in one file? Or should i call it a mini Django?

In Django, media files can be defined as those files which are uploaded by the users. For examples:

Profile Picture uploads
File Uploads and many more ...

Configurations
On our Django settings settings.py we add MEDIA_URL and MEDIA_ROOT settings
ME...

In Django, media files can be defined as those files which are uploaded by the users. For examples:
<ol>
<li>Profile Picture uploads</li>
<li>File Uploads and many more ...</li>
</ol>
<h4 id="heading-configurations">Configurations</h4>
On our Django settings <code>settings.py</code> we add <code>MEDIA_URL</code> and <code>MEDIA_ROOT</code> settings
<pre><code>MEDIA_URL='/media/'
MEDIA_ROOT = BASE_DIR /'media'
</code></pre>or 
<pre><code>MEDIA_ROOT = '/var/www/media/'
</code></pre><blockquote>
Note: <code>MEDIA_ROOT</code> is the folder where your file gets saved.
</blockquote>
<h4 id="heading-creating-a-url-configurations-so-serve-uploaded-files">Creating a URL configurations so serve uploaded files</h4>
In static files serving, Django would provide us with a way to serve static files automatically, But to serve the media files we will need to create a URL configurations to serve all media files from <code>MEDIA_ROOT</code>
<pre><code class="lang-py">from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
 # rest of project url patterns
]
if settings.DEBUG: 
 urlpatterns += static(settings.MEDIA_URL,
 document_root=settings.MEDIA_ROOT)
</code></pre>
<blockquote>
Note: we serve media files like this on local development environment only, on production servers we use a different approach. We serve these assets directly through the webserver.
Just to try if everything is working, you can create a sample file(<code>image.jpg</code>) inside the <code>MEDIA_ROOT</code> directory, and check if Django is serving it at <code>/media/image.jpg</code>
</blockquote>
<h4 id="heading-simple-file-upload-in-django">Simple File Upload in Django</h4>
<ul>
<li>When files are submitted from HTML form to server, the file data can be accessed from <code>request.FILES</code> on Django views. <code>request.FILES</code> is a dict like object</li>
<li>Each key in <code>request.FILES</code> is the name from <code>&lt;input type="file" name=""&gt;</code></li>
<li>It's mandatory for the HTML forms to have the attribute <code>enctype="multipart/form-data"</code></li>
<li>Form must be submitted using <code>POST</code> method</li>
<li>Django has proper model fields <code>ImageField</code> and <code>FileField</code> for handling file uploads</li>
<li>These uploaded files are stored on filesystem <code>(MEDIA_ROOT)</code> and only the reference of file is stored in <code>ImageField</code> or <code>FileField</code> in Database. So basically these fields are abstraction created by Django to help us deal with file uploads but deep down they are just the <code>CharField</code> on database side</li>
</ul>
Example: A basic file uploads, and handling the file uploads manually on the Django side
on HTML side,
<pre><code>&lt;!-- image-uploads.html --&gt;
&lt;form method="post" enctype="multipart/form-data"&gt;
 {% csrf_token %}
 &lt;input type="file" name="image"&gt;
 &lt;input type="submit" value="submit"&gt;
&lt;/form&gt;
</code></pre>on Django view side,
<pre><code class="lang-py">from django.core.files.storage import FileSystemStorage
from django.http import HttpResponse
from django.shortcuts import render

def image_upload(request):
 if request.method == 'POST' and request.FILES['image']:
 image = request.FILES['image']
 fs = FileSystemStorage()

 # save the image on MEDIA_ROOT folder
 file_name = fs.save(image.name, image)

 # get file url with respect to `MEDIA_URL`
 file_url = fs.url(file_name)
 return HttpResponse(file_url)
 else:
 # render the form
 return render(request, "image-uploads.html")
</code></pre>
That't it, now we can process file uploads in Django, save it to the <code>MEDIA_ROOT</code> location automatically using <code>FileSystemStorage()</code> 
<blockquote>
When using Django model and fields with <code>ImageFiled</code> or <code>FileField</code> we don't need to perform the file processing/saving manually like we did just now. Simply we would assign the file to the field, and call the model.save() method like we generally do. I will talk about it in detail in some other tutorial.
</blockquote>

In Django, media files can be defined as those files which are uploaded by the users. For examples:
Profile Picture uploads
File Uploads and many more ...
Configurations
On our Django settings settings.py we add MEDIA_URL and MEDIA_ROOT settings
MEDIA_URL='/media/'
MEDIA_ROOT = BASE_DIR /'media'

or 
MEDIA_ROOT = '/var/www/media/'


Note: MEDIA_ROOT is the folder where your file gets saved.
Creating a URL configurations so serve uploaded files
In static files serving, Django would provide us with a way to serve static files automatically, But to serve the media files we will need to create a URL configurations to serve all media files from MEDIA_ROOT
from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
 # rest of project url patterns
]
if settings.DEBUG: 
 urlpatterns += static(settings.MEDIA_URL,
 document_root=settings.MEDIA_ROOT)

Note: we serve media files like this on local development environment only, on production servers we use a different approach. We serve these assets directly through the webserver.
Just to try if everything is working, you can create a sample file(image.jpg) inside the MEDIA_ROOT directory, and check if Django is serving it at /media/image.jpg
Simple File Upload in Django
When files are submitted from HTML form to server, the file data can be accessed from request.FILES on Django views. request.FILES is a dict like object
Each key in request.FILES is the name from <input type="file" name="">
It's mandatory for the HTML forms to have the attribute enctype="multipart/form-data"
Form must be submitted using POST method
Django has proper model fields ImageField and FileField for handling file uploads
These uploaded files are stored on filesystem (MEDIA_ROOT) and only the reference of file is stored in ImageField or FileField in Database. So basically these fields are abstraction created by Django to help us deal with file uploads but deep down they are just the CharField on database side
Example: A basic file uploads, and handling the file uploads manually on the Django side
on HTML side,

<form method="post" enctype="multipart/form-data">
 {% csrf_token %}
 <input type="file" name="image">
 <input type="submit" value="submit">
</form>

on Django view side,
from django.core.files.storage import FileSystemStorage
from django.http import HttpResponse
from django.shortcuts import render

def image_upload(request):
 if request.method == 'POST' and request.FILES['image']:
 image = request.FILES['image']
 fs = FileSystemStorage()

 # save the image on MEDIA_ROOT folder
 file_name = fs.save(image.name, image)

 # get file url with respect to `MEDIA_URL`
 file_url = fs.url(file_name)
 return HttpResponse(file_url)
 else:
 # render the form
 return render(request, "image-uploads.html")

That't it, now we can process file uploads in Django, save it to the MEDIA_ROOT location automatically using FileSystemStorage() 
When using Django model and fields with ImageFiled or FileField we don't need to perform the file processing/saving manually like we did just now. Simply we would assign the file to the field, and call the model.save() method like we generally do. I will talk about it in detail in some other tutorial.

Django Media Files

When we develop a web application we also need a way to use and serve static contents like (JS,CSS, and images ...)
In Django, any assets which are required for project development can be called static files. Some examples are:

JS files

CSS files

...

When we develop a web application we also need a way to use and serve static contents like (JS,CSS, and images ...)
In Django, any assets which are required for project development can be called static files. Some examples are:
<ol>
<li>JS files
</li>
<li>CSS files
</li>
<li>Logo and banners which i need to show on webpage
</li>
</ol>
<blockquote>
These <code>static</code> files are put in place by developers rather than the user, User uploaded files like (profile picture, CV) are called <code>media</code> files in Django which we will talk in next tutorial
</blockquote>
<h4 id="heading-configure-static-files-settings">Configure static files settings</h4>
<ul>
<li>Make sure <code>django.contrib.staticfiles</code> is included on <code>INSTALLED_APPS</code>
</li>
<li>In your <code>settings.py</code> file, add <code>STATIC_URL</code> (e.g.: STATIC_URL = '/static/')
</li>
<li>Store your static files in folder called <code>static</code> inside your django app
</li>
</ul>
Apart from storing static files inside django app's <code>static</code> folder, we can also provide Django with list of other directories as well. To do that, we need to configure <code>STATICFILES_DIRS</code> on our <code>settings.py</code> file
<pre><code class="lang-plaintext"># settings.py
STATICFILES_DIRS = [
 BASE_DIR/"static", 
 "/data/django-project/static-images/",
 "/var/www/static-django/"
]
</code></pre>
<h3 id="heading-linking-static-files-on-html-templates">Linking static files on HTML Templates</h3>
Let's assume, <code>logo.jpg</code> exists in our app <code>static</code> folder (any app)
Now, your HTML templates would look like,
<pre><code>
{% load static %}

&lt;img src="{% static 'logo.jpg' %}"&gt;
</code></pre><blockquote>
If you run this template through Django (creating views and URLs) and inspect the HTML source of your page, you will see <code>&lt;img src="{% static 'logo.jpg' %}"</code> replaced by <code>&lt;img src="/static/logo.jpg"&gt;</code>. the <code>/static/</code> part that got appended in the URL is from the <code>STATIC_URL</code> settings we kept on our Django settings <code>(settings.py)</code>
</blockquote>
<h3 id="heading-serving-static-files">Serving static files</h3>
We just linked our static file on the Templates, but we also need a way to serve those static files, e.g: when browsers requests to <code>/static/logo.jpg</code> then our Django server must send the logo.jpg as response.
<ul>
<li>If we use <code>django.contrib.staticfiles</code> as explained above, <code>python manage.py runserver</code> command will automatically serve static files when <code>DEBUG</code> is set to True <code>[ DEBUG=True on settings.py ]</code></li>
</ul>
So this means, we do not need to create a new URL or view to serve these static files, because Django does this for us
<blockquote>
This way is not suitable for production, and on production environment we don't user <code>runserver</code> instead we use some <code>wsgi</code> or <code>asgi</code> servers with some webservers like <code>nginx</code>. We we see more about it on Django deployments series.
</blockquote>
<h4 id="heading-static-files-deployment-for-production-deployment-only">Static files Deployment (for production deployment only)</h4>
On production environment, since as discussed earlier we don't use Django built in static file serving mechanism, so we need a way to gather and collect all static files from all the static folders into one single folder, so that we can deploy this folder or serve content from this folder.
<code>django.contrib.staticfiles</code> provides a command for gathering static files from different applications of the project in a single directory so you can serve them easily. Steps:
<ol>
<li>Set <code>STATIC_ROOT</code> on settings.py <code>(e.g: STATIC_ROOT='/home/static/')</code>
</li>
<li>Run <code>collectstatic</code> command <code>(python manage.py collectstatic)</code>
</li>
</ol>

When we develop a web application we also need a way to use and serve static contents like (JS,CSS, and images ...)
In Django, any assets which are required for project development can be called static files. Some examples are:
JS files
CSS files
Logo and banners which i need to show on webpage
These static files are put in place by developers rather than the user, User uploaded files like (profile picture, CV) are called media files in Django which we will talk in next tutorial
Configure static files settings
Make sure django.contrib.staticfiles is included on INSTALLED_APPS
In your settings.py file, add STATIC_URL (e.g.: STATIC_URL = '/static/')
Store your static files in folder called static inside your django app
Apart from storing static files inside django app's static folder, we can also provide Django with list of other directories as well. To do that, we need to configure STATICFILES_DIRS on our settings.py file
# settings.py
STATICFILES_DIRS = [
 BASE_DIR/"static", 
 "/data/django-project/static-images/",
 "/var/www/static-django/"
]

Linking static files on HTML Templates
Let's assume, logo.jpg exists in our app static folder (any app)
Now, your HTML templates would look like,

{% load static %}

<img src="{% static 'logo.jpg' %}">


If you run this template through Django (creating views and URLs) and inspect the HTML source of your page, you will see <img src="{% static 'logo.jpg' %}" replaced by <img src="/static/logo.jpg">. the /static/ part that got appended in the URL is from the STATIC_URL settings we kept on our Django settings (settings.py)
Serving static files
We just linked our static file on the Templates, but we also need a way to serve those static files, e.g: when browsers requests to /static/logo.jpg then our Django server must send the logo.jpg as response.
If we use django.contrib.staticfiles as explained above, python manage.py runserver command will automatically serve static files when DEBUG is set to True [ DEBUG=True on settings.py ]
So this means, we do not need to create a new URL or view to serve these static files, because Django does this for us
This way is not suitable for production, and on production environment we don't user runserver instead we use some wsgi or asgi servers with some webservers like nginx. We we see more about it on Django deployments series.
Static files Deployment (for production deployment only)
On production environment, since as discussed earlier we don't use Django built in static file serving mechanism, so we need a way to gather and collect all static files from all the static folders into one single folder, so that we can deploy this folder or serve content from this folder.
django.contrib.staticfiles provides a command for gathering static files from different applications of the project in a single directory so you can serve them easily. Steps:
Set STATIC_ROOT on settings.py (e.g: STATIC_ROOT='/home/static/')
Run collectstatic command (python manage.py collectstatic)

Django Static Files

As the name suggests, Django views can also be written in Class based style. The major advantage of using Class based views in Django is

Code reusability and Clean Code

But, when creating a complex Class with lots of inheritance or mixins can make ...

As the name suggests, Django views can also be written in Class based style. The major advantage of using Class based views in Django is
<ul>
<li>Code reusability and Clean Code</li>
</ul>
But, when creating a complex Class with lots of inheritance or mixins can make the situation hard to debug. 
To create a Class() based view we subclass <code>django.views.View</code>
<pre><code class="lang-PY">from django.views import View
class DashboardView(View):
 def get(self, request):
 # GET method 
 pass
 def post(self, request):
 # POST method
 pass
</code></pre>
Converting examples from our function() based views to Class() based views
<pre><code class="lang-py">from django.views import View
from django.http impoty HttpResponse

class DashboardView(View):
 def get(self, request):
 # process view here
 return HttpResponse("Welcome to Dashboard")
</code></pre>
<pre><code class="lang-py">#urls.py
urlpatterns = [
 path('dashboard/', DashboardView),
]
# this will not work
</code></pre>
Since URL configurations expects callable function rather than class, we will use <code>.as_view()</code> class method of our View because <code>as_view()</code> returns a function to be used with URLs. This function does series of work for us,
<ol>
<li>calls <code>setup()</code> method to initialize the attributes</li>
<li>calls <code>dispatch()</code> method which determines if request if <code>GET</code> or <code>POST</code> and send this request to corresponding request method </li>
</ol>
So on our <code>urls.py</code> we do the following,
<pre><code class="lang-py"># urls.py
# import your view 

urlpatterns = [
 path('dashboard/', DashboardView.as_view()),
]
</code></pre>
<h4 id="heading-capturing-url-values-in-class-based-views">Capturing URL values in Class() based views</h4>
If you need to capture values from URL here at Class() based view, its similar to the function() based view, just add the new parameters(arguments) in your respective method. 
<pre><code>#urls.py
urlpatterns = [
 path('profile/&lt;str:username&gt;/', ProfileView.as_view()),
]
</code></pre><pre><code class="lang-py">from django.views import View
from django.http impoty HttpResponse

class ProfileView(View):
 def get(self, request, username):
 # process view here
 # get user info from DB using username
 return HttpResponse("My Profile")
</code></pre>
<blockquote>
Note: To make the development fast and easy, Django provides us with generic class based views as well majorly for performing C-R-U-D operations, which we will talk about in another tutorial <a target="_blank" href="https://docs.djangoproject.com/en/4.1/topics/class-based-views/generic-display/">See Django Docs for Generic class based views</a>
</blockquote>

As the name suggests, Django views can also be written in Class based style. The major advantage of using Class based views in Django is
Code reusability and Clean Code
But, when creating a complex Class with lots of inheritance or mixins can make the situation hard to debug. 
To create a Class() based view we subclass django.views.View
from django.views import View
class DashboardView(View):
 def get(self, request):
 # GET method 
 pass
 def post(self, request):
 # POST method
 pass

Converting examples from our function() based views to Class() based views
from django.views import View
from django.http impoty HttpResponse

class DashboardView(View):
 def get(self, request):
 # process view here
 return HttpResponse("Welcome to Dashboard")

#urls.py
urlpatterns = [
 path('dashboard/', DashboardView),
]
# this will not work

Since URL configurations expects callable function rather than class, we will use .as_view() class method of our View because as_view() returns a function to be used with URLs. This function does series of work for us,
calls setup() method to initialize the attributes
calls dispatch() method which determines if request if GET or POST and send this request to corresponding request method 
So on our urls.py we do the following,
# urls.py
# import your view 

urlpatterns = [
 path('dashboard/', DashboardView.as_view()),
]

Capturing URL values in Class() based views
If you need to capture values from URL here at Class() based view, its similar to the function() based view, just add the new parameters(arguments) in your respective method. 
#urls.py
urlpatterns = [
 path('profile/<str:username>/', ProfileView.as_view()),
]

from django.views import View
from django.http impoty HttpResponse

class ProfileView(View):
 def get(self, request, username):
 # process view here
 # get user info from DB using username
 return HttpResponse("My Profile")

Note: To make the development fast and easy, Django provides us with generic class based views as well majorly for performing C-R-U-D operations, which we will talk about in another tutorial See Django Docs for Generic class based views

Django Views - Class() based

When we talk about views in Django, views are the core part of Django which serves as the main place to process the incoming request.
Basically, we write out the view function in the views.py file, but we can write this function on a different file a...

When we talk about views in Django, views are the core part of Django which serves as the main place to process the incoming request.
Basically, we write out the view function in the <code>views.py</code> file, but we can write this function on a different file as well. We just need to map this function with our URL configuration.
Creating a function based view is quite easy, we just need to create a normal python function with first parameter <code>request</code> as mandatory, because this parameter is the <code>Request Object</code> which we may need on our views. Request Objects contains various useful information about the requests like <code>request method</code> ,<code>request data</code> and so on.
Also, this function based view must return an <code>HttpResponse</code> or its valid subclasses which is very important since a HTTP Response contains various information which Django configures automatically. 
Basic Example;
<pre><code class="lang-py">from django.http import HttpResponse
def dashboard_view(request):
 # write your view processing logics here
 return HttpResponse("Welcome to Dashboard")
</code></pre>
<blockquote>
To return a template we use <code>render()</code> function instead of <code>HttpResponse()</code>, but if you look into the code of this shortcut <code>render()</code> function it uses <code>HttpResponse()</code> at the end.
 <a target="_blank" href="https://github.com/django/django/blob/main/django/shortcuts.py#L17-L25">Django Github : django.shortcuts.render()</a>
</blockquote>
<h3 id="heading-allow-only-specific-request-method-on-views">Allow only specific request method on views</h3>
When we work with views, we sometime need a way to allow only specific request method like <code>GET</code> or <code>POST</code> according to our need. The basic way to perform this can be by doing if/else check on the view itself 
<pre><code class="lang-py">from django.http import HttpResponse
def dashboard_view(request):
 if request.method == 'GET'
 return HttpResponse("Welcome to Dashboard")
 else:
 # send status= 405 which means method not allowed
 return HttpResponse(status=405)
</code></pre>
But we can perform this with help of view decorator <code>require_http_methods</code>
<pre><code class="lang-py">from django.http import HttpResponse
from django.views.decorators.http import require_http_methods

@require_http_methods(["GET"])
def dashboard_view(request):
 # only GET allowed
 return HttpResponse("Welcome to Dashboard")
</code></pre>
<h4 id="heading-adding-extra-parameter-on-view-to-capture-url-values">Adding extra parameter on view to capture URL values</h4>
If you are capturing values from URL then your view function should have parameter to accept this values
<pre><code class="lang-py"># urls.py
urlpatterns = [
 path('/profile/&lt;str:username&gt;/', user_profile_detail_view) # we used &lt;str&gt; path converter and assigned the value to username
]
</code></pre>
<pre><code class="lang-py"># views.py
def user_profile_detail_view(request, username):
 # do something with the username
 pass
</code></pre>
Have a detail read about URL design and URL values capturing at: <a target="_blank" href="https://djangotherightway.com/url-designing-and-url-kwargs-in-django">URL designing and URL kwargs in Django</a>

When we talk about views in Django, views are the core part of Django which serves as the main place to process the incoming request.
Basically, we write out the view function in the views.py file, but we can write this function on a different file as well. We just need to map this function with our URL configuration.
Creating a function based view is quite easy, we just need to create a normal python function with first parameter request as mandatory, because this parameter is the Request Object which we may need on our views. Request Objects contains various useful information about the requests like request method ,request data and so on.
Also, this function based view must return an HttpResponse or its valid subclasses which is very important since a HTTP Response contains various information which Django configures automatically. 
Basic Example;
from django.http import HttpResponse
def dashboard_view(request):
 # write your view processing logics here
 return HttpResponse("Welcome to Dashboard")

To return a template we use render() function instead of HttpResponse(), but if you look into the code of this shortcut render() function it uses HttpResponse() at the end.
 Django Github : django.shortcuts.render()
Allow only specific request method on views
When we work with views, we sometime need a way to allow only specific request method like GET or POST according to our need. The basic way to perform this can be by doing if/else check on the view itself 
from django.http import HttpResponse
def dashboard_view(request):
 if request.method == 'GET'
 return HttpResponse("Welcome to Dashboard")
 else:
 # send status= 405 which means method not allowed
 return HttpResponse(status=405)

But we can perform this with help of view decorator require_http_methods
from django.http import HttpResponse
from django.views.decorators.http import require_http_methods

@require_http_methods(["GET"])
def dashboard_view(request):
 # only GET allowed
 return HttpResponse("Welcome to Dashboard")

Adding extra parameter on view to capture URL values
If you are capturing values from URL then your view function should have parameter to accept this values
# urls.py
urlpatterns = [
 path('/profile/<str:username>/', user_profile_detail_view) # we used <str> path converter and assigned the value to username
]

# views.py
def user_profile_detail_view(request, username):
 # do something with the username
 pass

Have a detail read about URL design and URL values capturing at: URL designing and URL kwargs in Django

Django Views - function() based

I am a long fan and user of Cloudflare and with Cloudflare R2 i am more in love with cloudflare.
Cloudflare R2 is one of the amazing and interesting service that Cloudflare has released. It's called,

Rapid and Reliable Object Storage, minus the egre...

I am a long fan and user of Cloudflare and with Cloudflare R2 i am more in love with cloudflare.
Cloudflare R2 is one of the amazing and interesting service that Cloudflare has released. It's called,
<blockquote>
Rapid and Reliable Object Storage, minus the egress fees and gives you the freedom to create the multi-cloud architectures you desire with an S3-compatible distributed object storage.
</blockquote>
Which means, it's a object storage and the amazing part is egress charges is free.
You can try and play around R2 for free with its free Monthly Quota and trust me the free limit will be enough to build an app, up and running easily.
<h1 id="heading-grab-secret-keys-and-bucket-info-from-cloudflare">Grab secret keys and bucket info from Cloudflare</h1>
<ol>
<li>Creating a Bucket
 On Cloudflare Dashboard go to R2 and create a bucket
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1657710796774/uwbjxupsQ.png" alt="cloudflare-r2-create-bucket.png" />
<blockquote>
Note: As of now, Buckets can only be private.
</blockquote>
</li>
<li>Create API tokens to communicate with R2
 Go to <code>Manage R2 API Tokens</code> from R2 Dashboard and create a API token which consist of <code>access_key</code> and <code>secret_key</code>
</li>
<li>Make sure you copy these to safe location
<ul>
<li>Account ID : You can get it from the URL section, or from the bucket url or from the right most div on the R2 dashboard</li>
<li>Bucket name: You just created</li>
<li>Access key: You just obtained while creating API tokens</li>
<li>Secret Key: You just obtained while creating API tokens</li>
</ul>
</li>
</ol>
<h1 id="heading-implementing-on-django">Implementing on Django</h1>
Since, R2 is compatible with S3 apis* we can easily use third party packages that are using S3 api for object storage.
Let's install the required libraries
<pre><code>pip install django-storages
pip install boto3
</code></pre>on Django <code>settings.py</code> add the following,
<pre><code>
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
AWS_STORAGE_BUCKET_NAME = '&lt;YOUR_BUCKET_NAME&gt;'
AWS_S3_ENDPOINT_URL = 'https://&lt;YOUR_ACCOUNT_ID&gt;.r2.cloudflarestorage.com'
AWS_S3_ACCESS_KEY_ID = '&lt;YOUR_ACCESS_KEY&gt;'
AWS_S3_SECRET_ACCESS_KEY = '&lt;YOUR_SECRET_KEY&gt;'
AWS_S3_SIGNATURE_VERSION = 's3v4'
</code></pre><blockquote>
Make sure: signature version is <code>s3v4</code> since Cloudflare R2 doesn't support SigV2 and we need to explicitly set it to SigV4
</blockquote>
That's it, you can use Django freely with R2 now.
<h4 id="heading-general-tipshelps">General Tips/Helps</h4>
<ol>
<li>Since, R2 currently supports Private bucket only, every object should be pre signed. Using <code>django-storages</code> with the above configurations does that to us automatically. In simple word it means <code>generating a presigned url for object</code></li>
<li>Since, a bucket cannot be made public as of now, i wouldn't suggest storing static files from Django on R2</li>
<li>Since Cloudflare R2 api is compatible with S3 api, we are able to use <code>boto3</code> and S3 API to communicate with R2</li>
<li>Public Buckets are currently in roadmap but not implemented. (I am really waiting and excited for this)</li>
<li>Learn more about R2 from Cloudflare docs at <a target="_blank" href="https://developers.cloudflare.com/r2/">https://developers.cloudflare.com/r2/</a></li>
</ol>
<h5 id="heading-tested-on">Tested on</h5>
<ul>
<li>Django==4.0.6</li>
<li>django-storages==1.12.3</li>
<li>boto3==1.24.28</li>
</ul>
Last Updated: July 13, 2022

I am a long fan and user of Cloudflare and with Cloudflare R2 i am more in love with cloudflare.
Cloudflare R2 is one of the amazing and interesting service that Cloudflare has released. It's called,
Rapid and Reliable Object Storage, minus the egress fees and gives you the freedom to create the multi-cloud architectures you desire with an S3-compatible distributed object storage.
Which means, it's a object storage and the amazing part is egress charges is free.
You can try and play around R2 for free with its free Monthly Quota and trust me the free limit will be enough to build an app, up and running easily.
Grab secret keys and bucket info from Cloudflare
Creating a Bucket
 On Cloudflare Dashboard go to R2 and create a bucket

Note: As of now, Buckets can only be private.
Create API tokens to communicate with R2
 Go to Manage R2 API Tokens from R2 Dashboard and create a API token which consist of access_key and secret_key
Make sure you copy these to safe location
Account ID : You can get it from the URL section, or from the bucket url or from the right most div on the R2 dashboard
Bucket name: You just created
Access key: You just obtained while creating API tokens
Secret Key: You just obtained while creating API tokens
Implementing on Django
Since, R2 is compatible with S3 apis* we can easily use third party packages that are using S3 api for object storage.
Let's install the required libraries
pip install django-storages
pip install boto3

on Django settings.py add the following,

DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
AWS_STORAGE_BUCKET_NAME = '<YOUR_BUCKET_NAME>'
AWS_S3_ENDPOINT_URL = 'https://<YOUR_ACCOUNT_ID>.r2.cloudflarestorage.com'
AWS_S3_ACCESS_KEY_ID = '<YOUR_ACCESS_KEY>'
AWS_S3_SECRET_ACCESS_KEY = '<YOUR_SECRET_KEY>'
AWS_S3_SIGNATURE_VERSION = 's3v4'


Make sure: signature version is s3v4 since Cloudflare R2 doesn't support SigV2 and we need to explicitly set it to SigV4
That's it, you can use Django freely with R2 now.
General Tips/Helps
Since, R2 currently supports Private bucket only, every object should be pre signed. Using django-storages with the above configurations does that to us automatically. In simple word it means generating a presigned url for object
Since, a bucket cannot be made public as of now, i wouldn't suggest storing static files from Django on R2
Since Cloudflare R2 api is compatible with S3 api, we are able to use boto3 and S3 API to communicate with R2
Public Buckets are currently in roadmap but not implemented. (I am really waiting and excited for this)
Learn more about R2 from Cloudflare docs at https://developers.cloudflare.com/r2/
Tested on
Django==4.0.6
django-storages==1.12.3
boto3==1.24.28
Last Updated: July 13, 2022

Using Cloudflare R2 with Django for storage

Django under the hood provides an app called Admin a.k.a Django Admin, which provides Admin UI interface/web page for your Django Project. This admin interface can automatically generate CRUD views/ (form/tables) for your models with very minimal set...

Django under the hood provides an app called Admin a.k.a Django Admin, which provides Admin UI interface/web page for your Django Project. This admin interface can automatically generate CRUD views/ (form/tables) for your models with very minimal setup i.e (Registering your models to admin)
This Admin app is usually said to be one of the most powerful parts of Django
Let's deep to use Django Admin on our projects
<h3 id="heading-using-django-admin-registering-models">Using Django Admin/ Registering Models</h3>
<ol>
<li>Creating a test Model named Information
<pre><code class="lang-py"> # inside your models.py file
 from django.db import models

 class Information(models.Model):
 name = models.CharField(max_length=100)
 date_of_birth = models.DateField()
 salary = models.IntegerField()
</code></pre>
<blockquote>
Don't forget to create migrations and then migrate 
</blockquote>
</li>
<li>Registering your models to Django Admin
<ul>
<li>Open up <code>admin.py</code> file that exists in your app (when you create django app through <code>manage.py startapp [app]</code> command, you will automatically get this file along other files like <code>models.py</code> that we have been using)</li>
<li>To let Django Admin work for our models, we simply register our model class on this <code>admin.py</code> file, by using <code>admin.site.register()</code>
<pre><code class="lang-py">from django.contrib import admin

from .models import Information # import your model

admin.site.register(Information) # actual registration
</code></pre>
</li>
</ul>
</li>
<li>Create Superuser to login to Django Admin
<ul>
<li>Because Django also contains a built in Auth/User app which we can use to manage users and authentication, we can easily use this to create our superuser/login mechanism and everything works like a magic</li>
<li>You can always create a new <code>User</code> app and authentication process, but we will leave that for another tutorial</li>
<li>On your shell, run <code>python manage.py createsuperuser</code> command</li>
<li>This command will ask bunch of questions to fill up the <code>User table</code> with attributes <code>is_staff</code> and <code>is_superuser</code> set to True. This, attributes are the table columns</li>
<li>Django admin/UI login requires <code>is_staff</code> or <code>is_superuser</code> set to True for authorization</li>
<li>Which means, anyone, any user on our project can initiate login to the admin site but won't get access since other users <code>is_staff</code> and <code>is_superuser</code> are set to False
<pre><code>-&gt; python manage.py createsuperuser
Username (leave blank to use 'djangotherightway'): admin
Email address: admin@example.com
Password: 
Password (again): 
Superuser created successfully.
</code></pre></li>
</ul>
</li>
<li>login to Django Admin Site
<ul>
<li>So, we completed our core process for working out with Django Admin, we now need a URL through which we can access our Admin Site</li>
<li>Register Admin urls to our <code>urls.py</code>
<pre><code>from django.contrib import admin
from django.urls import path

urlpatterns = [
 path('admin/', admin.site.urls),
]
</code></pre></li>
<li>Now, we can access our admin site through /admin/ url</li>
<li>I suggest to change this from <code>/admin/</code> to something unguessable, so as to prevent users from bruteforcing this page or accessing this page. In production environment, i usually disable this url path<blockquote>
By default, when creating a project using <code>django-admin startproject [project]</code> command, Django will automatically do this for us
</blockquote>
</li>
<li>Run your Django server using <code>python manage.py runserver</code> and navigate to <code>/admin/</code>
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1648874387503/_bLy9801s.png" alt="djangotherightway-django-admin-login-page.png" />
</li>
<li>Now, login using the credentials we just created on Step-3, and you will be able to see the model we registered on Step-2
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1648874520555/aCXEBFZdH.png" alt="djangotherightway-django-admin-home-page.png" />
</li>
<li>You can now, perform CRUD operations to your models, like add a new object/row, view all objects/rows, update and delete
<blockquote>
You may see that <code>Groups</code> and <code>Users</code> models are already registered on Django admin through we didn't do it manually. This is because this <code>Auth</code> app has already registered those models on its <code>admin.py</code> file. You can see the code on github <a target="_blank" href="https://github.com/django/django/blob/main/django/contrib/auth/admin.py">here</a>
</blockquote>
</li>
</ul>
</li>
</ol>
<h3 id="heading-customizing-django-admin-site">Customizing Django Admin Site</h3>
Django admin site is super customizable, but we will see some basics so that you can get some idea about its customizations.
Customizing Admin view for models can be done through <code>admin.ModelAdmin</code> class. We basically create a class using/subclassing <code>admin.ModelAdmin</code> and then tell Django admin to use this custom ModelAdmin while registering a model
<ul>
<li><h4 id="heading-customize-table-display-field">Customize Table display field</h4>
<ul>
<li>When you see the table page for your models like from the above example, you will see something like this (assuming you have created two records/objects)
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1648879239263/Z5KIPUxTN.png?w=1000&amp;h=800" alt="a.png" /></li>
<li>This table view doesn't look nice, so lets add some columns/fields on this table view using <code>list_display</code> attributes on <code>admin.ModelAdmin</code>
<pre><code class="lang-py"> # on your admin.py 
 from django.contrib import admin
 from .models import Information

 class InformationAdmin(admin.ModelAdmin):
 list_display = ('name', 'date_of_birth', 'salary')

 admin.site.register(Information, InformationAdmin)
</code></pre>
</li>
<li>Now, save the changes and run your server, you will see the table now has name, date_of_birth and salary fields </li>
<li><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1648879374910/t0eobZTuu.png?w=1000&amp;h=800" alt="django-admin1.png" /></li>
</ul>
</li>
</ul>
<ul>
<li><h4 id="heading-add-custom-fields-to-table-list-display">Add custom fields to table List Display</h4>
<ul>
<li>Let's create up <code>age</code> field obtained from <code>date_of_birth</code> and display it on the list display table fields 
<pre><code class="lang-py"> from django.contrib import admin
 from .models import Information

 class InformationAdmin(admin.ModelAdmin):
 list_display = ('name', 'date_of_birth', 'salary', 'age')

 @admin.display()
 def age(self, obj):
 # this is rough implementation of finding
 # out age from date of birth, so as to keep
 # this example as easy as possible
 from datetime import datetime
 current_year = datetime.today().year
 born_year = obj.date_of_birth.year
 return current_year - born_year
</code></pre>
</li>
<li><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1648880272837/bFckMk2pV.png" alt="Screen Shot 2022-04-02 at 12.02.42.png" /></li>
</ul>
</li>
</ul>
<ul>
<li><h4 id="heading-adding-filters">Adding filters</h4>
<ul>
<li>We can use list_filters attribute to set filter fields
<pre><code class="lang-py"> from django.contrib import admin
 from .models import Information

 class InformationAdmin(admin.ModelAdmin):
 list_filters=['date_of_birth']

 admin.site.register(Information,InformationAdmin)
</code></pre>
</li>
<li><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1648880969794/y1MbLDGsS.png" alt="django-admin-filters.png" /></li>
</ul>
</li>
</ul>
<blockquote>
These were all basics things that we can do with Django Admin interface, but there are much more advance customizations available to use.
</blockquote>
If i should write more on advanced Customization, let me know in comments.

Django under the hood provides an app called Admin a.k.a Django Admin, which provides Admin UI interface/web page for your Django Project. This admin interface can automatically generate CRUD views/ (form/tables) for your models with very minimal setup i.e (Registering your models to admin)
This Admin app is usually said to be one of the most powerful parts of Django
Let's deep to use Django Admin on our projects
Using Django Admin/ Registering Models
Creating a test Model named Information
 # inside your models.py file
 from django.db import models

 class Information(models.Model):
     name = models.CharField(max_length=100)
     date_of_birth = models.DateField()
     salary = models.IntegerField()

Don't forget to create migrations and then migrate 
Registering your models to Django Admin
Open up admin.py file that exists in your app (when you create django app through manage.py startapp [app] command, you will automatically get this file along other files like models.py that we have been using)
To let Django Admin work for our models, we simply register our model class on this admin.py file, by using admin.site.register()
from django.contrib import admin

from .models import Information  # import your model

admin.site.register(Information) # actual registration

Create Superuser to login to Django Admin
Because Django also contains a built in Auth/User app which we can use to manage users and authentication, we can easily use this to create our superuser/login mechanism and everything works like a magic
You can always create a new User app and authentication process, but we will leave that for another tutorial
On your shell, run python manage.py createsuperuser command
This command will ask bunch of questions to fill up the User table with attributes is_staff and is_superuser set to True. This, attributes are the table columns
Django admin/UI login requires is_staff or is_superuser set to True for authorization
Which means, anyone, any user on our project can initiate login to the admin site but won't get access since other users is_staff and is_superuser are set to False
-> python manage.py createsuperuser
Username (leave blank to use 'djangotherightway'): admin
Email address: admin@example.com
Password: 
Password (again): 
Superuser created successfully.





login to Django Admin Site
So, we completed our core process for working out with Django Admin, we now need a URL through which we can access our Admin Site
Register Admin urls to our urls.py
from django.contrib import admin
from django.urls import path

urlpatterns = [
  path('admin/', admin.site.urls),
]


Now, we can access our admin site through /admin/ url
I suggest to change this from /admin/ to something unguessable, so as to prevent users from bruteforcing this page or accessing this page. In production environment, i usually disable this url path
By default, when creating a project using django-admin startproject [project] command, Django will automatically do this for us
Run your Django server using python manage.py runserver and navigate to /admin/

Now, login using the credentials we just created on Step-3, and you will be able to see the model we registered on Step-2

You can now, perform CRUD operations to your models, like add a new object/row, view all objects/rows, update and delete
You may see that Groups and Users models are already registered on Django admin through we didn't do it manually. This is because this Auth app has already registered those models on its admin.py file. You can see the code on github here
Customizing Django Admin Site
Django admin site is super customizable, but we will see some basics so that you can get some idea about its customizations.
Customizing Admin view for models can be done through admin.ModelAdmin class. We basically create a class using/subclassing admin.ModelAdmin  and then tell Django admin to use this custom ModelAdmin while registering a model
Customize Table display field
When you see the table page for your models like from the above example, you will see something like this (assuming you have created two records/objects)

This table view doesn't look nice, so lets add some columns/fields on this table view using list_display attributes on admin.ModelAdmin
  # on your admin.py 
  from django.contrib import admin
  from .models import Information

  class InformationAdmin(admin.ModelAdmin):
      list_display = ('name', 'date_of_birth', 'salary')

  admin.site.register(Information, InformationAdmin)

Now, save the changes and run your server, you will see the table now has name, date_of_birth and salary fields 

Add custom fields to table List Display
Let's create up age field obtained from date_of_birth and display it on the list display table fields 
  from django.contrib import admin
  from .models import Information

  class InformationAdmin(admin.ModelAdmin):
      list_display = ('name', 'date_of_birth', 'salary', 'age')

      @admin.display()
      def age(self, obj):
          # this is rough implementation of finding
          # out age from date of birth, so as to keep
          # this example as easy as possible
          from datetime import datetime
          current_year = datetime.today().year
          born_year = obj.date_of_birth.year
          return current_year - born_year


Adding filters
We can use list_filters attribute to set filter fields
  from django.contrib import admin
  from .models import Information

  class InformationAdmin(admin.ModelAdmin):
      list_filters=['date_of_birth']

  admin.site.register(Information,InformationAdmin)


These were all basics things that we can do with Django Admin interface, but there are much more advance customizations available to use.
If i should write more on advanced Customization, let me know in comments.

Django Admin (Registering Models, Customizing Admin Site)

Model Field Validation
To validate a model field on application level we can create up a validator which is a callable that take the value to be validated and raises error (ValidationError to be precise) if the value doesn't meet the criteria or it i...

<h3 id="heading-model-field-validation">Model Field Validation</h3>
To validate a model field on application level we can create up a <code>validator</code> which is a callable that take the value to be validated and raises error (<code>ValidationError</code> to be precise) if the value doesn't meet the criteria or it is invalid
The <code>ValidationError</code> it raises can be imported as <code>from django.core.exceptions import ValidationError</code>
<h4 id="heading-1-individual-field-validation">1. Individual Field validation</h4>
We can add callable validators to our model field through <code>validators</code> arguments
Let's take a simple example of a model having a field <code>email</code> which requires <code>@djangotherightway.com</code> emails to be valid
<pre><code class="lang-py">from django.core.exceptions import ValidationError
from django.db import models

def django_the_right_way_email_validator(email):
 if not email.endswith('@djangotherightway.com'):
 raise ValidationError('Email must end with @djangotherightway.com')

class Info(models.Model):
 email = models.EmailField(
 validators=[django_the_right_way_email_validator]
 )
</code></pre>
<blockquote>
You can add as many validator function/callables to a field
</blockquote>
<h4 id="heading-2-validating-multiple-fields-together">2. Validating multiple fields together</h4>
Sometime we come up for a need to validate two or more field together or are dependent on each other, in such scenario we can use <code>clean()</code> method provided by <code>models.Model</code>
Let's add up simple requirements on our previous model example. Let's add up <code>phone_number</code> and <code>age</code> to our model, and imagine a situation where <code>phone_number</code> is required if <code>age&gt;20</code>
<pre><code class="lang-py">from django.core.exceptions import ValidationError
from django.db import models

def django_the_right_way_email(email):
 if not email.endswith('@djangotherightway.com'):
 raise ValidationError('Email must end with @djangotherightway.com')

class Info(models.Model):
 email = models.EmailField(
 validators=[django_the_right_way_email]
 )
 # make phone nullable, since phone_number is
 # required only if age&gt;20
 phone_number = models.CharField(
 max_length=10, null=True, blank=True
 )
 age = models.IntegerField()

 def clean(self):
 if self.age &gt; 20:
 if not self.phone_number:
 raise ValidationError(
 'Phone number is required if age is greater than 20'
 )
</code></pre>
<h4 id="heading-running-validators">Running Validators</h4>
These validators we created will not run automatically when you create/update object/row. To make this validators run, we need to call <code>full_clean()</code> method which under the hood runs all the validator
<blockquote>
Note: Validators run automatically when using <code>ModelForm</code>
</blockquote>
<pre><code class="lang-py"># this code can be on your view func or ...
# ...for this example you can use django shell 
# Open Django shell using: python manage.py shell
obj = Info()
obj.email = "example@djangotherightway.com"
obj.age = 21
obj.phone_number = '1234567890'
try:
 obj.full_clean()
except ValidationError as e:
 print(e)
else:
 obj.save()
</code></pre>
<blockquote>
Have a look into <a target="_blank" href="https://github.com/django/django/blob/main/django/db/models/base.py#L1397">full_clean() Django code:Github</a> where it runs all individual field validators like <code>django_the_right_way_email</code> in our case and even runs <code>clean()</code> method we implemented for validations
You can call <code>full_clean()</code> from your models <code>save()</code> method, so that you don't have to manually call <code>full_clean()</code> everytime while validating objects, but this might bring up another issue of <code>full_clean()</code> being called two times in case using <code>ModelForm</code>.
</blockquote>
<h3 id="heading-built-in-validators">Built-in validators</h3>
Django already has a collection of validators used for general purpose that we can use openly as a function/callable validator to our <code>Model field</code> or <code>Forms</code> or you own data validation
These built-in validators can be imported from <code>django.core.validators</code> module
Some list of commonly used built-in validators are <code>validate_email</code>, <code>validate_slug</code>, <code>validate_ipv4_address</code>, <code>validate_ipv6_address</code>, <code>int_list_validator</code>, <code>validate_image_file_extension</code> e.t.c
A simple example to demonstrate use of built-in validators
<pre><code class="lang-py">from django.db import models
from django.core.validators import validate_email

class Info(models.Model):
 # we didn't make email=models.EmailField() 
 # because models.EmailField() would already contain
 # validate_email validator that checks for 
 # valid email addresses
 email = models.CharField(validators=[validate_email])
</code></pre>
<h3 id="heading-django-models-meta-class">Django models Meta class</h3>
Model Meta class in Django is a way to provide some more information regarding <code>table_name</code> <code>whether model is abstract</code> <code>singular or plural names</code> <code>app_label</code> <code>ordering</code> and many more....
<blockquote>
Python metaclass is different than that of Django model meta class. Metaclass in Python are class factory where as meta class in Django is completely different which is used to provide additional information about a model to Django. Don't get confused on they sharing the same name during our <code>pronouncing</code> <code>speaking</code> <code>listening</code> but they are way different on writings.
</blockquote>
<h4 id="heading-basic-example-of-creating-meta-options-class-in-django">Basic example of creating <code>Meta</code> options class in Django</h4>
Django automatically create a <code>database table</code> for every models in the format of <code>{app_name}_{model_name}</code>, so lets customize this behaviour and provide it with a custom <code>table name</code>
<pre><code class="lang-py">from django.db import models

class Address(models.Model):
 name = models.CharField(max_length=100)

 class Meta:
 db_table = 'address'
</code></pre>
Now, when we create <code>migrations file</code> and run our migrations through <code>migrate</code> command, django will create a table named <code>address</code> instead of its default <code>{app_name}_address</code>
<h4 id="heading-available-models-meta-options">Available Models Meta Options</h4>
<ol>
<li>abstract<ul>
<li>if <code>abstract=True</code> this model will be a abstract model class</li>
</ul>
</li>
<li>db_table<ul>
<li>if <code>db_table</code> is set to a value, Django will take this value to create <code>database table</code> like we saw in previous example</li>
</ul>
</li>
<li>managed<ul>
<li>if <code>managed=True</code> (default behaviour) Django will create and manage database table for this model</li>
<li>if <code>managed=False</code> table is not created. This might be useful to integrate already existing table into Django</li>
</ul>
</li>
<li>ordering<ul>
<li>default ordering when retrieving list of objects/rows</li>
</ul>
</li>
<li>verbose_name<ul>
<li>Human readable name for the singular object</li>
</ul>
</li>
<li>verbose_name_plural<ul>
<li>Human readable plural name for the object</li>
</ul>
</li>
</ol>
<h3 id="heading-abstract-model-base-class-abstracttrue">Abstract Model Base class (abstract=True)</h3>
Abstract model base class is also a model class which is used to place common <code>model fields</code> used in other models into a single model so that it can be used/inherited into other <code>model</code>. 
<ul>
<li>This type of model will not be used to create and <code>Database Table</code> by the <code>migrations framework</code></li>
<li>Since, this type of model doesn't create database table, we cannot perform any queries on this model</li>
<li>This type of models are inherited on other models to obtain features/fields from abstract model to normal model</li>
<li>So, this abstract base class is useful when you want to group common logics/fields of models into a single model but do not want to create it's corresponding database table</li>
</ul>
<h5 id="heading-lets-take-example-of-simple-information-abstract-base-class">Let's take example of simple <code>Information</code> abstract base class</h5>
<pre><code class="lang-py">from django.db import models

class InfoBase(models.Model):
 name = models.CharField(max_length=100)
 email = models.EmailField()

 class Meta:
 abstract = True
</code></pre>
<h5 id="heading-lets-use-this-abstract-class-to-form-other-normal-model-class">Let's use this abstract class to form other normal model class</h5>
<pre><code class="lang-py">class User(InfoBase):
 address = models.CharField(max_length=100)
</code></pre>
So, the <code>User</code> model will now have fields <code>name</code> <code>email</code> <code>address</code>, where <code>name</code> and <code>email</code> is inherited from the <code>InfoBase</code> abstract model class
<ol>
<li>Override fields in child model 
 Some time, we may need to override some fields from the base class so that it gets changed in our child class. let's take an example we need to change <code>max_length</code> of name in <code>User</code>, we can do it by
<pre><code class="lang-py">class User(InfoBase):
 name = models.CharField(max_length=50) # changed
 address = models.CharField(max_length=100)
</code></pre>
</li>
<li>Remove/delete fields in child model
 Some time, there may occur a case when we need to delete/remove some fields in our child class, we can do it by simply overriding the fields with <code>None</code> value
<pre><code class="lang-py">class User(InfoBase):
 name = models.CharField(max_length=50)
 email = None
 address = models.CharField(max_length=100)
</code></pre>
 So, considering this example, <code>User</code> model will only have <code>name</code> and <code>address</code> fields
</li>
</ol>

Model Field Validation
To validate a model field on application level we can create up a validator which is a callable that take the value to be validated and raises error (ValidationError to be precise) if the value doesn't meet the criteria or it is invalid
The ValidationError it raises can be imported as from django.core.exceptions import ValidationError
1. Individual Field validation
We can add callable validators to our model field through validators arguments
Let's take a simple example of a model having a field email which requires @djangotherightway.com emails to be valid
from django.core.exceptions import ValidationError
from django.db import models

def django_the_right_way_email_validator(email):
    if not email.endswith('@djangotherightway.com'):
        raise ValidationError('Email must end with @djangotherightway.com')

class Info(models.Model):
    email = models.EmailField(
        validators=[django_the_right_way_email_validator]
    )

You can add as many validator function/callables to a field
2. Validating multiple fields together
Sometime we come up for a need to validate two or more field together or are dependent on each other, in such scenario we can use clean() method provided by models.Model
Let's add up simple requirements on our previous model example. Let's add up phone_number and age to our model, and imagine a situation where phone_number is required if age>20
from django.core.exceptions import ValidationError
from django.db import models

def django_the_right_way_email(email):
    if not email.endswith('@djangotherightway.com'):
        raise ValidationError('Email must end with @djangotherightway.com')

class Info(models.Model):
    email = models.EmailField(
        validators=[django_the_right_way_email]
    )
    # make phone nullable, since phone_number is
    # required only if age>20
    phone_number = models.CharField(
        max_length=10, null=True, blank=True
    )
    age = models.IntegerField()

    def clean(self):
        if self.age > 20:
            if not self.phone_number:
                raise ValidationError(
                    'Phone number is required if age is greater than 20'
                )

Running Validators
These validators we created will not run automatically when you create/update object/row. To make this validators run, we need to call full_clean() method which under the hood runs all the validator
Note: Validators run automatically when using ModelForm
# this code can be on your view func or ...
# ...for this example you can use django shell 
#  Open Django shell using: python manage.py shell
obj = Info()
obj.email = "example@djangotherightway.com"
obj.age = 21
obj.phone_number = '1234567890'
try:
    obj.full_clean()
except ValidationError as e:
    print(e)
else:
    obj.save()

Have a look into full_clean() Django code:Github where it runs all individual field validators like django_the_right_way_email in our case and even runs clean() method we implemented for validations
You can call full_clean() from your models save() method, so that you don't have to manually call full_clean() everytime while validating objects, but this might bring up another issue of full_clean() being called two times in case using ModelForm.
Built-in validators
Django already has a collection of validators used for general purpose that we can use openly as a function/callable validator to our Model field or Forms or you own data validation
These built-in validators can be imported from django.core.validators module
Some list of commonly used built-in validators are validate_email, validate_slug, validate_ipv4_address, validate_ipv6_address, int_list_validator, validate_image_file_extension e.t.c
A simple example to demonstrate use of built-in validators
from django.db import models
from django.core.validators import validate_email

class Info(models.Model):
    # we didn't make email=models.EmailField() 
    #  because models.EmailField() would already contain
    #  validate_email validator that checks for 
    #  valid email addresses
    email = models.CharField(validators=[validate_email])

Django models Meta class
Model Meta class in Django is a way to provide some more information regarding table_name whether model is abstract singular or plural names app_label ordering and many more....
Python metaclass is different than that of Django model meta class. Metaclass in Python are class factory where as meta class in Django is completely different which is used to provide additional information about a model to Django. Don't get confused on they sharing the same name during our pronouncing speaking listening but they are way different on writings.
Basic example of creating Meta options class in Django
Django automatically create a database table for every models in the format of {app_name}_{model_name}, so lets customize this behaviour and provide it with a custom table name
from django.db import models

class Address(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        db_table = 'address'

Now, when we create migrations file and run our migrations through migrate command, django will create a table named address instead of its default {app_name}_address
Available Models Meta Options
abstract
if abstract=True this model will be a abstract model class
db_table
if db_table is set to a value, Django will take this value to create database table like we saw in previous example
managed
if managed=True (default behaviour) Django will create and manage database table for this model
if managed=False table is not created. This might be useful to integrate already existing table into Django
ordering
default ordering when retrieving list of objects/rows
verbose_name
Human readable name for the singular object
verbose_name_plural
Human readable plural name for the object
Abstract Model Base class (abstract=True)
Abstract model base class is also a model class which is used to place common model fields used in other models into a single model so that it can be used/inherited into other model. 
This type of model will not be used to create and Database Table by the migrations framework
Since, this type of model doesn't create database table, we cannot perform any queries on this model
This type of models are inherited on other models to obtain features/fields from abstract model to normal model
So, this abstract base class is useful when you want to group common logics/fields of models into a single model but do not want to create it's corresponding database table
Let's take example of simple Information abstract base class
from django.db import models

class InfoBase(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField()

    class Meta:
        abstract = True

Let's use this abstract class to form other normal model class
class User(InfoBase):
    address = models.CharField(max_length=100)

So, the User model will now have fields name email address, where name and email is inherited from the InfoBase abstract model class
Override fields in child model 
 Some time, we may need to override some fields from the base class so that it gets changed in our child class. let's take an example we need to change max_length of name in User, we can do it by
class User(InfoBase):
     name = models.CharField(max_length=50) # changed
     address = models.CharField(max_length=100)

Remove/delete fields in child model
  Some time, there may occur a case when we need to delete/remove some fields in our child class, we can do it by simply overriding the fields with None value
class User(InfoBase):
     name = models.CharField(max_length=50)
     email = None
     address = models.CharField(max_length=100)

 So, considering this example, User model will only have name and address fields

Django Models Part 4 (Model validation, Model Meta, Abstract Model class)

Model Manager

A Manager is the interface through which we perform ORMs in Django models
By Default, Django automatically adds a Manager with a name of objects. This is the reason we are able to use objects and query to our Models eg: Model.objects.a...

<h3 id="heading-model-manager">Model Manager</h3>
<ul>
<li>A <code>Manager</code> is the interface through which we perform ORMs in Django models</li>
<li>By Default, Django automatically adds a <code>Manager</code> with a name of <code>objects</code>. This is the reason we are able to use <code>objects</code> and query to our Models <code>eg: Model.objects.all()</code></li>
<li>We can always create a new Manager and add to our model. We can customize ORM methods or add some more functionality in our Manager for data query</li>
<li>Atleast one Manager should exist in every models</li>
</ul>
Example to change rename default <code>objects</code> in our model
<pre><code class="lang-py">from django.db import models

class Info(models.Model):
 name = models.CharField(max_length=100)

 data = models.Manager()

# Info.objects.all() will not work but Info.data.all() will work
</code></pre>
<h3 id="heading-queryset">QuerySet</h3>
<ul>
<li>QuerySet can be defined as a collection of Objects (model objects)</li>
<li>Until and unless you do something to evaluate a QuerySet <code>(loop, slice with increments,...)</code>, it doesn't hit your database. So, we call it by saying QuerSet is Lazy</li>
</ul>
<h4 id="heading-lets-take-an-example-of-basic-model-which-we-will-be-using-in-this-tutorial">Let's take an example of basic model which we will be using in this tutorial</h4>
<ul>
<li>All, methods, customizations will be done on basis of this model below</li>
</ul>
<pre><code class="lang-py">from django.db import models

class User(models.Model):
 name = models.CharField(max_length=100)
 age = models.IntegerField()
</code></pre>
<h4 id="heading-queryset-methods">QuerySet Methods</h4>
<ol>
<li>filter()
<ul>
<li>Returns a new QuerySet, list of objects that matches the given lookup criteria</li>
<li>To return list of <code>users</code> whose <code>age</code>=10, we can do <code>User.objects.filter(age=10)</code>;<pre><code class="lang-py">qs = User.objects.filter(age=10)
for u in qs:
print(u.name, u.age)
</code></pre>
</li>
<li>Multiple arguments are joined by <code>AND</code> clause when crafting an SQL query</li>
<li>So, <code>User.objects.filter(age=10, name="John")</code> will return list of <code>users</code> whose <code>age</code> is <code>10</code> <code>AND</code> whose <code>name</code> is <code>John</code></li>
<li>If you need to join arguments with <code>OR</code> you can use <code>Q</code> objects. e.g. This example will return list of users whose name is <code>John</code> <code>OR</code> <code>Harry</code> <pre><code class="lang-py">from django.db.models import Q
qs = User.objects.filter(Q(name='John') | Q(name='Harry'))
</code></pre>
</li>
</ul>
</li>
<li>exclude()
<ul>
<li>Returns a new Queryset, list of objects that do not match the given lookup criteria</li>
<li>Same like <code>filter()</code> multiple arguments/parameters are joined by <code>AND</code> clause</li>
<li><code>User.objects.exclude(age=20)</code> will return list of users whose <code>age</code> is not <code>20</code></li>
</ul>
</li>
<li>order_by()
<ul>
<li>Used to perform some ordering for the return QuerySet list</li>
<li>If you have set default ordering for your models, you don't even have to use this method to order your <code>QuerySet</code>, because the results returned by <code>QuerySet</code> are ordered automatically by the ordering tuple given by the <code>ordering</code> option in models <code>Meta</code>
<pre><code class="lang-py">class User(models.Model):
 name = models.CharField(max_length=100)
 age = models.IntegerField()

 class Meta:
 ordering = ['-age'] # - negative sign for descending order and
 # no sign for asc order
</code></pre>
</li>
<li><code>User.objects.filter(age=10)</code> on this model will return the list of users whose <code>age</code> is <code>10</code> in descending order of <code>age</code></li>
<li><code>User.objects.filter(age=10).order_by('age')</code> on this model will return the list of users whose <code>age</code> is <code>10</code> in ascending order of <code>age</code></li>
<li><code>User.objects.order_by('-name')</code> will return list of users in descending order</li>
</ul>
</li>
</ol>
<ol>
<li>none()
<ul>
<li>Calling <code>none()</code> will create a <code>QuerySet</code> that will never return any objects</li>
<li>This doesn't return any data, so this can be used in place where we need a valid <code>QuerySet</code> but no data</li>
<li>calling <code>none()</code> will not hit database</li>
<li>e.g <code>User.objects.none()</code></li>
</ul>
</li>
<li>all()
<ul>
<li>This method is the simplest way to retrieve all objects from the model</li>
<li><code>User.objects.all()</code> will return list of every users/objects</li>
</ul>
</li>
</ol>
<h4 id="heading-database-orm-methods-which-do-not-return-a-queryset">Database ORM methods which do not return a QuerySet</h4>
<ol>
<li>get()<ul>
<li><code>User.objects.get(id=1)</code> will return the row/object whose <code>id</code> is <code>1</code></li>
</ul>
</li>
<li>create()<ul>
<li><code>User.objects.create(name="Peter",age=25)</code> will create a new object/record in database and return that object</li>
</ul>
</li>
<li>first()<ul>
<li><code>User.objects.filter(id=10).first()</code> will return the first row/object whose <code>id</code> is <code>10</code></li>
</ul>
</li>
<li>last()<ul>
<li><code>User.objects.filter(id=10).last()</code> will return the last row/object whose <code>id</code> is <code>10</code></li>
</ul>
</li>
<li>delete()<ul>
<li><code>User.objects.filter(id=10).delete()</code> will delete objects/rows whose <code>id</code> is <code>10</code>. This works like a bulk delete</li>
<li>You can also perform <code>delete()</code> on model single objects like the objects obtained from <code>get()</code> <code>first()</code> <code>last()</code> methods. This works like a single object delete</li>
</ul>
</li>
<li>count()<ul>
<li><code>User.objects.filter(id=10).count()</code> will return total number of users/objects whose <code>id</code> is <code>10</code></li>
</ul>
</li>
</ol>
<h3 id="heading-field-lookups">Field Lookups</h3>
<ul>
<li>Field lookups are used to specify meaning to the SQL <code>WHERE</code> clause</li>
<li>These lookups are crafted and attached with the fields when performing an ORM queries</li>
<li>It looks like<ul>
<li><code>field_[LookupType]=value</code> [note the double underscores]</li>
</ul>
</li>
</ul>
<h4 id="heading-lookups-types">Lookups Types</h4>
<ol>
<li>exact (also a default lookup)
<ul>
<li>An exact Match</li>
<li><code>User.objects.filter(name__exact="Peter")</code> would generate <code>SQL: select .... where name="Peter"</code> and returns the objects/rows whose name is <code>Peter</code><blockquote>
If we do not provide a lookup like in the above <code>QuerySet</code> method examples, Django automatically uses <code>exact</code> lookup. This is the reason our ORMs were working even when we didn't pass any lookups
</blockquote>
</li>
<li>Thus, <code>User.objects.filter(name__exact="Peter")</code> and <code>User.objects.filter(name="Peter")</code> QuerySet is practically the same</li>
</ul>
</li>
<li>iexact
<ul>
<li>Case insensitive match</li>
<li><code>User.objects.filter(name__iexact="peter")</code> would return QuerySet of the list of users whose name is <code>peter(case insensitive)</code> i.e: <code>peter</code>, <code>Peter</code>, <code>PeTeR</code>, <code>peteR</code> e.t.c</li>
</ul>
</li>
<li>contains
<ul>
<li>Case sensitive containment</li>
<li><code>User.objects.filter(name__contains="a")</code> would generate <code>SQL: select ..... where name like '%a%'</code> and would return QuerySet of list of users whose <code>name</code> contains/includes <code>a</code></li>
</ul>
</li>
<li>icontains
<ul>
<li>Similar to <code>contains</code> but case-insensitive</li>
</ul>
</li>
<li>gt
<ul>
<li>greater than </li>
<li><code>User.objects.filter(age_gt=10)</code> would return QuerySet of list of users whose age is greater than 10 i.e 11,12,13,.......</li>
</ul>
</li>
<li>gte
<ul>
<li>greater than or equal to</li>
<li><ul>
<li><code>User.objects.filter(age_gte=10)</code> would return QuerySet of list of users whose age is greater than or equals to 10 i.e 10,11,12,13,.......</li>
</ul>
</li>
</ul>
</li>
<li>lt
<ul>
<li>less than </li>
<li><code>User.objects.filter(age_lt=10)</code> would return QuerySet of list of users whose age is less than 10 i.e 9,8,7,......</li>
</ul>
</li>
<li>lte
<ul>
<li>less than or equal to</li>
<li><ul>
<li><code>User.objects.filter(age_lte=10)</code> would return QuerySet of list of users whose age is less than or equals to 10 i.e 10,9,8,7,.....</li>
</ul>
</li>
</ul>
</li>
</ol>
<blockquote>
There are other plenty of inbuilts lookups. To name some of them; <code>in</code> <code>startswith</code> <code>istartswith</code> <code>range</code> 
</blockquote>

Model Manager
A Manager is the interface through which we perform ORMs in Django models
By Default, Django automatically adds a Manager with a name of objects. This is the reason we are able to use objects and query to our Models eg: Model.objects.all()
We can always create a new Manager and add to our model. We can customize ORM methods or add some more functionality in our Manager for data query
Atleast one Manager should exist in every models
Example to change rename default objects in our model
from django.db import models

class Info(models.Model):
    name = models.CharField(max_length=100)

    data = models.Manager()

# Info.objects.all() will not work but Info.data.all() will work

QuerySet
QuerySet can be defined as a collection of Objects (model objects)
Until and unless you do something to evaluate a QuerySet (loop, slice with increments,...), it doesn't hit your database. So, we call it by saying QuerSet is Lazy
Let's take an example of basic model which we will be using in this tutorial
All, methods, customizations will be done on basis of this model below
from django.db import models

class User(models.Model):
    name = models.CharField(max_length=100)
    age = models.IntegerField()

QuerySet Methods
filter()
Returns a new QuerySet, list of objects that matches the given lookup criteria
To return list of users whose age=10, we can do User.objects.filter(age=10);
qs = User.objects.filter(age=10)
for u in qs:
print(u.name, u.age)

Multiple arguments are joined by AND clause when crafting an SQL query
So, User.objects.filter(age=10, name="John") will return list of users whose age is 10 AND whose name is John
If you need to join arguments with OR you can use Q objects. e.g. This example will return list of users whose name is John OR Harry 
from django.db.models import Q
qs = User.objects.filter(Q(name='John') | Q(name='Harry'))

exclude()
Returns a new Queryset, list of objects that do not match the given lookup criteria
Same like filter() multiple arguments/parameters are joined by AND clause
User.objects.exclude(age=20) will return list of users whose age is not 20
order_by()
Used to perform some ordering for the return QuerySet list
If you have set default ordering for your models, you don't even have to use this method to order your QuerySet, because the results returned by QuerySet are ordered automatically by the ordering tuple given by the ordering option in models Meta
class User(models.Model):
  name = models.CharField(max_length=100)
  age = models.IntegerField()

  class Meta:
      ordering = ['-age'] # - negative sign for descending order and
                      # no sign for asc order

User.objects.filter(age=10) on this model will return the list of users whose age is 10 in descending order of age
User.objects.filter(age=10).order_by('age') on this model will return the list of users whose age is 10 in ascending order of age
User.objects.order_by('-name') will return list of users in descending order
none()
Calling none() will create a QuerySet that will never return any objects
This doesn't return any data, so this can be used in place where we need a valid QuerySet but no data
calling none() will not hit database
e.g User.objects.none()
all()
This method is the simplest way to retrieve all objects from the model
User.objects.all() will return list of every users/objects
Database ORM methods which do not return a QuerySet
get()
User.objects.get(id=1) will return the row/object whose id is 1
create()
User.objects.create(name="Peter",age=25) will create a new object/record in database and return that object
first()
User.objects.filter(id=10).first() will return the first row/object whose id is 10
last()
User.objects.filter(id=10).last() will return the last row/object whose id is 10
delete()
User.objects.filter(id=10).delete() will delete objects/rows whose id is 10. This works like a bulk delete
You can also perform delete() on model single objects like the objects obtained from get() first() last() methods. This works like a single object delete
count()
User.objects.filter(id=10).count() will return total number of users/objects whose id is 10
Field Lookups
Field lookups are used to specify meaning to the SQL WHERE clause
These lookups are crafted and attached with the fields when performing an ORM queries
It looks like
field_[LookupType]=value [note the double underscores]
Lookups Types
exact (also a default lookup)
An exact Match
User.objects.filter(name__exact="Peter") would generate SQL: select .... where name="Peter" and returns the objects/rows whose name is Peter
If we do not provide a lookup like in the above QuerySet method examples, Django automatically uses exact lookup. This is the reason our ORMs were working even when we didn't pass any lookups
Thus, User.objects.filter(name__exact="Peter") and User.objects.filter(name="Peter") QuerySet is practically the same
iexact
Case insensitive match
User.objects.filter(name__iexact="peter") would return QuerySet of the list of users whose name is peter(case insensitive) i.e: peter, Peter, PeTeR, peteR e.t.c
contains
Case sensitive containment
User.objects.filter(name__contains="a") would generate SQL: select ..... where name like '%a%' and would return QuerySet of list of users whose name contains/includes a
icontains
Similar to contains but case-insensitive
gt
greater than 
User.objects.filter(age_gt=10) would return QuerySet of list of users whose age is greater than 10 i.e 11,12,13,.......
gte
greater than or equal to

User.objects.filter(age_gte=10) would return QuerySet of list of users whose age is greater than or equals to 10 i.e 10,11,12,13,.......
lt
less than 
User.objects.filter(age_lt=10) would return QuerySet of list of users whose age is less than 10 i.e 9,8,7,......
lte
less than or equal to

User.objects.filter(age_lte=10) would return QuerySet of list of users whose age is less than or equals to 10 i.e 10,9,8,7,.....
There are other plenty of inbuilts lookups. To name some of them; in startswith istartswith range

Django Models Part 3 (Model Manager,  QuerySet,  Lookups)

Table relationships in Relational Database design
1.  One to One relationship (1-1)

A relation is said to be 1-1 if a row in Table A can have only one matching row in Table B
Let's take an example of simple 1-1 relationship between user and user_det...

<h2 id="heading-table-relationships-in-relational-database-design">Table relationships in Relational Database design</h2>
<h3 id="heading-1-one-to-one-relationship-1-1">1. One to One relationship (1-1)</h3>
<ul>
<li>A relation is said to be 1-1 if a row in <code>Table A</code> can have only one matching row in <code>Table B</code></li>
<li>Let's take an example of simple 1-1 relationship between <code>user</code> and <code>user_detail</code> table
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1647813459928/F5uFc0FKT.png" alt="one-to-one.djangotherightway.com.png" />
</li>
<li>Here, in this figure we can see that, a row from <code>user table (Table A)</code> can only reference <code>a row (1 row)</code> for <code>user_detail (Table B)</code> through <code>user_detail_id</code> 
column on <code>user table (Table A)</code>
</li>
<li>Practically speaking, all data stored on <code>user_detail table (table B)</code> could have been stored on <code>user table (Table A)</code> and we could have just ignored the relationship, but this relationship is quite useful when you have lot's of column in your table and you want to separate those columns in different table according to their business nature</li>
<li>I basically work with this relationship to make my data model/table more readable</li>
</ul>
<h4 id="heading-lets-implement-1-1-relation-on-django-onetoonefield">Let's implement (1-1) relation on Django (<code>OneToOneField</code>)</h4>
<pre><code class="lang-py"># models.py
from django.db import models

class UserDetail(models.Model):
 address = models.CharField(max_length=100)
 phone_number = models.CharField(max_length=20)
 date_of_birth = models.DateField()
 github_username = models.CharField(max_length=50)

class User(models.Model):
 first_name = models.CharField(max_length=50)
 middle_name = models.CharField(max_length=50, null=True, blank=True)
 last_name = models.CharField(max_length=50)
 email = models.EmailField()
 # note: do not save password in plain text 
 password = models.CharField(max_length=50)
 user_detail = models.OneToOneField(UserDetail,
 on_delete=models.CASCADE)
</code></pre>
so using <code>models.OneToOneField</code> we can easily create up 1-1 relation between different models in Django. 
<blockquote>
You could have switched the relationship as well, i.e 1-1 relation from UserDetail to User
</blockquote>
Basic ORM to create data/rows for this relation
<pre><code class="lang-py"># import your model 
# i.e from app.models import UserDetail, User
detail = UserDetail.objects.create(
 address="Lake Street",
 phone_number='123456',
 date_of_birth='2000-01-01',
 github_username='django'
)

user = User.objects.create(
 first_name='Django',
 last_name='Django',
 email="django@example.com",
 password="django",
 user_detail=detail # reference to the user_detail instance created above
)
</code></pre>
<h3 id="heading-2-one-to-many-relationship-1-m">2. One to Many Relationship (1-M)</h3>
<ul>
<li>One of the most common forms of relationships</li>
<li>A relationship is said to be 1-M if a row in <code>Table A</code> can have matching row in <code>Table B</code> but a row in <code>Table B</code> can only have one matching row in <code>Table A</code></li>
<li>Let's take an example of simple 1-M relationship between <code>address</code> and <code>user</code> table</li>
</ul>
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1647815733365/BAE9roUwa.png" alt="one-to-many.djangotherightway.com.png" />
<ul>
<li>Here, in the figure we can see that a row in <code>address (Table A)</code> can be referenced by many rows from <code>user (Table B)</code>. i.e a user can have only one address but a address can be of multiple users</li>
<li>This can be simplified as <code>1 Address = Multiple Users</code> but <code>1 User = 1 Address</code></li>
<li>Experiment: Lets take an imaginary requirement of <code>1 User= Multiple Address</code> and <code>1 Address = 1 User</code>, in such a case, we can reverse this relation and call it <code>Multiple Address = 1 User</code> and call this relation a <code>Reverse One to Many Relation</code> as shown in the figure below</li>
</ul>
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1647816549866/WUDv6UNN2.png" alt="reverse.1-m.djangotherightway.com.png" />
<blockquote>
Now, there lies a big confusion on the 1-M and Reverse 1-M, because both looks same. Infact, both of them looks same, but the only difference occurs when you look the relationship from table point of view. i.e In the reverse 1-M figure, we named it Reverse relation because we looked the relation from <code>address</code> point of view, but if you had looked the relation from <code>user</code> point of view, then it would have been a normal 1-M relation
How you prepare your 1-M relation matters when you try to perform db query for the data
</blockquote>
<h4 id="heading-lets-implement-1-m-relation-on-django-foreignkey">Let's implement (1-M) relation on Django (<code>ForeignKey</code>)</h4>
<pre><code class="lang-py">from django.db import models

class Address(models.Model):
 name = models.CharField(max_length=100)
 latitude = models.CharField(max_length=100)
 longitude = models.CharField(max_length=100)

class User(models.Model):
 email = models.EmailField()
 name = models.CharField(max_length=50)
 password = models.CharField(max_length=50)
 address = models.ForeignKey(Address, on_delete=models.CASCADE)
</code></pre>
Basic ORM to create rows for this relation
<pre><code class="lang-py">address = Address.objects.create(
 name="Lake Street",
 latitude='1.1',
 longitude='2.2',
)
# or to get already created object
# address = Address.objects.get(name='Lake Street')

user = User.objects.create(
 name='Django',
 email="django@example.com",
 password="django",
 address=address # reference to the address instance from above
)
</code></pre>
<h3 id="heading-3-many-to-many-relationship-m-m">3. Many to Many Relationship (M-M)</h3>
<ul>
<li>A row in <code>Table A</code> can have many matching rows in <code>Table B</code> and vice versa</li>
<li>A many-to-many relation can be defined as a one-to-many relation linked by an intermediate table</li>
<li>Under the hood this relation is created using two <code>1-M</code> relation. i.e <code>1-M</code> and <code>M-1</code></li>
<li>Let's take an example of simple M-M relationship between <code>user</code> and <code>address</code> table</li>
</ul>
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1647817884669/r21scyytt.png" alt="many-to-many.djangotherightway.com.png" />
<ul>
<li>As you can see in the figure, the relation between <code>user</code> and <code>address</code> is maintained by an intermediate table <code>Table C</code>, this way we can achieve a relation where a <code>user</code> can have multiple <code>address</code> and a <code>address</code> can have multiple <code>user</code></li>
</ul>
<h4 id="heading-lets-implement-m-m-relation-on-django-manytomanyfield">Let's implement (M-M) relation on Django (<code>ManyToManyField</code>)</h4>
<pre><code class="lang-py">from django.db import models

class Address(models.Model):
 name = models.CharField(max_length=100)
 latitude = models.CharField(max_length=100)
 longitude = models.CharField(max_length=100)

class User(models.Model):
 email = models.EmailField()
 name = models.CharField(max_length=50)
 password = models.CharField(max_length=50)
 address = models.ManyToManyField(Address)
</code></pre>
<blockquote>
This looks so simple, isn't it? But i can feel a big confusion. We discussed that a M-M relation would need an intermediate table but on the Django end we just created two models without an intermediate one, This is due to the awesome implementation of Django where, Django automatically creates an intermediate table when we define our field with <code>models.ManyToManyField</code>, but don't worry you can always tell <code>models.ManyToManyField</code> to point to some custom intermediate table or you can even implement <code>M-M</code> with just <code>1-M</code> and <code>M-1</code> relation without even using <code>models.ManyToManyField</code>
</blockquote>
Basic ORM to create rows for this relation
<pre><code class="lang-py">address = Address.objects.create(
 name="Lake Street",
 latitude='1.1',
 longitude='2.2',
)
# or to get already created object
# address = Address.objects.get(name='Lake Street')

# first create user object
user = User.objects.create(
 name='Django',
 email="django@example.com",
 password="django",
)

# add address to user/user to address
user.address.add(address)

# to remove address from user/user from address
user.address.remove(address)
</code></pre>
<h4 id="heading-implementing-m-m-without-modelsmanytomanyfield">Implementing M-M without <code>models.ManyToManyField</code></h4>
By using just <code>1-M</code> relation and an intermediate table let's try to create M-M relations
<pre><code class="lang-py">from django.db import models

class Address(models.Model):
 name = models.CharField(max_length=100)
 latitude = models.CharField(max_length=100)
 longitude = models.CharField(max_length=100)

class User(models.Model):
 email = models.EmailField()
 name = models.CharField(max_length=50)
 password = models.CharField(max_length=50)

# intermediate table
class UserAddress(models.Model):
 user = models.ForeignKey(User, on_delete=models.CASCADE)
 address = models.ForeignKey(Address, on_delete=models.CASCADE)
</code></pre>
Basic ORM for this custom way
<pre><code class="lang-py">address = Address.objects.create(
 name="Lake Street",
 latitude='1.1',
 longitude='2.2',
)
user = User.objects.create(
 name='Django',
 email="django@example.com",
 password="django",
)

user_address = UserAddress.objects.create(
 user=user,
 address=address,
)
</code></pre>
<h3 id="heading-relation-field-arguments">Relation field Arguments</h3>
<ol>
<li>on_delete
As you can see we used <code>on_delete</code> argument on our <code>OneToOneField</code> and <code>ForeignKey</code> field, but what does it do?
<ul>
<li>When an object/row referenced by ForeignKey/OneToOneField is deleted, Django will emulate the behaviour of SQL constraint specified by the on_delete argument</li>
<li>e.g.1 You have a <code>ForeignKey</code> and want to delete the row when the object referenced by foreign key gets deleted</li>
</ul>
<pre><code class="lang-py"> from django.db import models
 class Info(models.Model):
 name=models.CharField(max_length=20)
 user= models.ForeignKey(User, on_delete=models.CASCASE)
</code></pre>
 Here, The <code>Info</code> objects/rows gets deleted when the referenced user gets deleted on the <code>User</code> table
<h4 id="heading-commonly-used-values-for-ondelete">Commonly used Values for <code>on_delete</code></h4>
<ul>
<li><code>models.CASCADE</code></li>
<li><code>models.PROTECT</code></li>
<li><code>models.SET_NULL</code>
and more...</li>
</ul>
</li>
<li>related_name
<ul>
<li><code>related_name</code> attribute specifies the name of the reverse relation</li>
<li>If you do not provide <code>related_name</code> Django automatically created <code>related_name</code> for every <code>FK</code> automatically, whose default value is:<ol>
<li>[name of class]_set for <code>ForeignKey</code></li>
<li>[name_of_class] for <code>OneToOneField</code></li>
</ol>
</li>
</ul>
</li>
</ol>

Table relationships in Relational Database design
1.  One to One relationship (1-1)
A relation is said to be 1-1 if a row in Table A can have only one matching row in Table B
Let's take an example of simple 1-1 relationship between user and user_detail  table

Here, in this figure we can see that, a row from user table (Table A) can only reference  a row (1 row) for user_detail (Table B) through user_detail_id 
column on user table (Table A)
Practically speaking, all data stored on user_detail table (table B) could have been stored on user table (Table A) and we could have just ignored the relationship, but this relationship is quite useful when you have lot's of column in your table and you want to separate those columns in different table according to their business nature
I basically work with this relationship to make my data model/table more readable
Let's implement (1-1) relation on Django (OneToOneField)
# models.py
from django.db import models

class UserDetail(models.Model):
    address = models.CharField(max_length=100)
    phone_number = models.CharField(max_length=20)
    date_of_birth = models.DateField()
    github_username = models.CharField(max_length=50)

class User(models.Model):
    first_name = models.CharField(max_length=50)
    middle_name = models.CharField(max_length=50, null=True, blank=True)
    last_name = models.CharField(max_length=50)
    email = models.EmailField()
    # note: do not save password in plain text 
    password = models.CharField(max_length=50)
    user_detail = models.OneToOneField(UserDetail,
                           on_delete=models.CASCADE)

so using models.OneToOneField we can easily create up 1-1 relation between different models in Django. 
You could have switched the relationship as well, i.e 1-1 relation from UserDetail to User
Basic ORM to create data/rows for this relation
# import your model 
# i.e from app.models import UserDetail, User
detail = UserDetail.objects.create(
    address="Lake Street",
    phone_number='123456',
    date_of_birth='2000-01-01',
    github_username='django'
)

user = User.objects.create(
    first_name='Django',
    last_name='Django',
    email="django@example.com",
    password="django",
    user_detail=detail  # reference to the user_detail instance created above
)

2. One to Many Relationship (1-M)
One of the most common forms of relationships
A relationship is said to be 1-M if a row in Table A can have matching row in Table B but a row in Table B can only have one matching row in Table A
Let's take an example of simple 1-M relationship between address and user table

Here, in the figure we can see that a row in address (Table A) can be referenced by many rows from user (Table B). i.e a user can have only one address but a address can  be of multiple users
This can be simplified as 1 Address = Multiple Users but 1 User = 1 Address
Experiment: Lets take an imaginary requirement of  1 User= Multiple Address and 1 Address = 1 User, in such a case, we can reverse this relation and call it Multiple Address = 1 User and call this relation a Reverse One to Many Relation as shown in the figure below

Now, there lies a big confusion on the 1-M and Reverse 1-M, because both looks same. Infact, both of them looks same, but the only difference occurs when you look the relationship from table point of view. i.e In the reverse 1-M figure, we named it Reverse relation because we looked the relation from address point of view, but if you had looked the relation from user point of view, then it would have been a normal 1-M relation
How you prepare your 1-M relation matters when you try to perform db query for the data
Let's implement (1-M) relation on Django (ForeignKey)
from django.db import models

class Address(models.Model):
    name = models.CharField(max_length=100)
    latitude = models.CharField(max_length=100)
    longitude = models.CharField(max_length=100)

class User(models.Model):
    email = models.EmailField()
    name = models.CharField(max_length=50)
    password = models.CharField(max_length=50)
    address = models.ForeignKey(Address, on_delete=models.CASCADE)

Basic ORM to create rows for this relation
address = Address.objects.create(
    name="Lake Street",
    latitude='1.1',
    longitude='2.2',
)
# or to get already created object
# address = Address.objects.get(name='Lake Street')

user = User.objects.create(
    name='Django',
    email="django@example.com",
    password="django",
    address=address  # reference to the address instance from above
)

3. Many to Many Relationship (M-M)
A row in Table A can have many matching rows in Table B and vice versa
A many-to-many relation can be defined as a one-to-many relation linked by an intermediate table
Under the hood this relation is created using two 1-M relation. i.e 1-M and M-1
Let's take an example of simple M-M relationship between user and address  table

As you can see in the figure, the relation between user and address is maintained by an intermediate table Table C, this way we can achieve a relation where a user can have multiple address and a address can have multiple user
Let's implement (M-M) relation on Django (ManyToManyField)
from django.db import models

class Address(models.Model):
    name = models.CharField(max_length=100)
    latitude = models.CharField(max_length=100)
    longitude = models.CharField(max_length=100)

class User(models.Model):
    email = models.EmailField()
    name = models.CharField(max_length=50)
    password = models.CharField(max_length=50)
    address = models.ManyToManyField(Address)

This looks so simple, isn't it? But i can feel a big confusion. We discussed that a M-M relation would need an intermediate table but on the Django end we just created two models without an intermediate one, This is due to the awesome implementation of Django where, Django automatically creates an intermediate table when we define our field with models.ManyToManyField, but don't worry you can always tell models.ManyToManyField to point to some custom intermediate table or you can even implement M-M with just 1-M and M-1 relation without even using models.ManyToManyField
Basic ORM to create rows for this relation
address = Address.objects.create(
    name="Lake Street",
    latitude='1.1',
    longitude='2.2',
)
# or to get already created object
# address = Address.objects.get(name='Lake Street')

# first create user object
user = User.objects.create(
    name='Django',
    email="django@example.com",
    password="django",
)

# add address to user/user to address
user.address.add(address)

# to remove address from user/user from address
user.address.remove(address)

Implementing M-M without models.ManyToManyField
By using just 1-M relation and an intermediate table let's try to create M-M relations
from django.db import models

class Address(models.Model):
    name = models.CharField(max_length=100)
    latitude = models.CharField(max_length=100)
    longitude = models.CharField(max_length=100)

class User(models.Model):
    email = models.EmailField()
    name = models.CharField(max_length=50)
    password = models.CharField(max_length=50)

# intermediate table
class UserAddress(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    address = models.ForeignKey(Address, on_delete=models.CASCADE)

Basic ORM for this custom way
address = Address.objects.create(
    name="Lake Street",
    latitude='1.1',
    longitude='2.2',
)
user = User.objects.create(
    name='Django',
    email="django@example.com",
    password="django",
)

user_address = UserAddress.objects.create(
    user=user,
    address=address,
)

Relation field Arguments
on_delete
As you can see we used on_delete argument on our OneToOneField and ForeignKey field, but what does it do?
When an object/row referenced by ForeignKey/OneToOneField is deleted, Django will emulate the behaviour of SQL constraint specified by the on_delete argument
e.g.1 You have a ForeignKey and want to delete the row when the object referenced by foreign key gets deleted
 from django.db import models
 class Info(models.Model):
           name=models.CharField(max_length=20)
           user= models.ForeignKey(User, on_delete=models.CASCASE)

  Here, The Info objects/rows gets deleted when the referenced user gets deleted on the User table
Commonly used Values for on_delete
models.CASCADE
models.PROTECT
models.SET_NULL
and more...
related_name
related_name attribute specifies the name of the reverse relation
If you do not provide related_name Django automatically created related_name for every FK automatically, whose default value is:
[name of class]_set for ForeignKey
[name_of_class] for OneToOneField

Django Models Part 2 (Models Relationship)

When talking about LimitOffsetPagination in django rest framework, it handles limit as strictly positive integer only (1,2,3,4.......). Whenever you send any non positive numbers/negative numbers including zero (0) to the limit query LimitOffsetPagin...

When talking about <code>LimitOffsetPagination</code> in django rest framework, it handles <code>limit</code> as strictly positive integer only <code>(1,2,3,4.......)</code>. Whenever you send any <code>non positive numbers/negative numbers</code> including <code>zero (0)</code> to the <code>limit query</code> <code>LimitOffsetPagination</code> will ignore this limit value and will work with it's own customizable <code>default_limit</code> attribute which indeed can be customized using <code>PAGE_SIZE</code> settings for <code>REST_FRAMEWORK</code>
<h2 id="heading-lets-talk-about-my-scenario">Let's talk about my scenario</h2>
Whenever i send <code>limit=0</code> params for the pagination, it ignores this values and sends/returns me whole lot of data(according to <code>default_limit</code>). I wanted to change this behaviour of the <code>LimitOffsetPagination</code> class so that the pagination class return <code>empty data</code> i.e <code>zero data</code> when i send <code>limit=0</code> params
<h3 id="heading-so-lets-customize-the-limitoffsetpagination-class">so, lets customize the <code>LimitOffsetPagination</code> class</h3>
<pre><code class="lang-py">from rest_framework.pagination import LimitOffsetPagination, _positive_int

class LimitZeroNoResultsPagination(LimitOffsetPagination):
 def get_limit(self, request):
 if self.limit_query_param:
 try:
 return _positive_int(
 request.query_params[self.limit_query_param],
 strict=False,
 cutoff=self.max_limit
 )
 except (KeyError, ValueError):
 pass

 return self.default_limit
</code></pre>
If, you compare what we customized in this class then you can see we changed <code>strict=False</code> for the <code>_positive_int</code> function
Note: <code>_positive_int</code> is a private function, i do not promote using private func but in this case i needed it so please use this responsibly.
So, when you use this Pagination class for your API's and use <code>limit=0</code> then you will see this
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1647056226646/d2RGAt-iC.png" alt="limit-zero-no-results-paginations.png" />
<h3 id="heading-where-do-i-use-this">Where do i use this ?</h3>
I use this <code>limit=0</code> whenever i want extra data from the API like the <code>total count</code> but don't want it's data
<h4 id="heading-tested-on">Tested on</h4>
<ul>
<li>Django(3.0.3) and Django Rest Framework(3.11.0)</li>
<li>Django(4.0.2) and Django Rest Framework(3.13.1)</li>
</ul>

When talking about LimitOffsetPagination in django rest framework, it handles limit as strictly positive integer only (1,2,3,4.......). Whenever you send any non positive numbers/negative numbers including zero (0) to the limit query LimitOffsetPagination will ignore this limit value and will work with it's own customizable default_limit attribute which indeed can be customized using PAGE_SIZE settings for REST_FRAMEWORK
Let's talk about my scenario
Whenever i send limit=0 params for the pagination, it ignores this values and sends/returns me whole lot of data(according to default_limit). I wanted to change this behaviour of the LimitOffsetPagination class so that the pagination class return empty data i.e zero data when i send limit=0 params
so, lets customize the LimitOffsetPagination class
from rest_framework.pagination import LimitOffsetPagination, _positive_int

class LimitZeroNoResultsPagination(LimitOffsetPagination):
    def get_limit(self, request):
        if self.limit_query_param:
            try:
                return _positive_int(
                    request.query_params[self.limit_query_param],
                    strict=False,
                    cutoff=self.max_limit
                )
            except (KeyError, ValueError):
                pass

        return self.default_limit

If, you compare what we customized in this class then you can see we changed strict=False for the _positive_int function
Note: _positive_int is a private function, i do not promote using private func but in this case i needed it so please use this responsibly.
So, when you use this Pagination class for your API's and use limit=0 then you will see this

Where do i use this ?
I use this limit=0 whenever i want extra data from the API like the total count but don't want it's data
Tested on
Django(3.0.3) and Django Rest Framework(3.11.0)
Django(4.0.2) and Django Rest Framework(3.13.1)

Django Rest Framework: LimitZeroNoResultsPagination custom pagination

While working with Django+Django Rest Framework, you might have come up in a problem that occurrence of Errors/ValidationErrors from Django Model or some internals will not response a valid json your API consumer was expecting.
For example:
Errors/Va...

While working with Django+Django Rest Framework, you might have come up in a problem that occurrence of Errors/ValidationErrors from Django Model or some internals will not response a valid <code>json</code> your API consumer was expecting.
For example:
Errors/ValidationErrors from Django Model or some internals will output something like
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1646840079461/d5SrIsvNT.png" alt="django-error-debug-mode-example.png" />
This looks so ugly (on debug mode only!), but with <code>DEBUG=False</code> as well, you will get something like
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1646840429795/-ujo5wyau.png" alt="500-error-example.png" />
So, let's create up a custom exception handler for Django Rest Framework which will catch exceptions from those above mentioned scenarios and convert them to something much more prettier which can be easily transformed to <code>json</code> 
<pre><code class="lang-py">from django.core.exceptions import NON_FIELD_ERRORS as DJ_NON_FIELD_ERRORS
from django.core.exceptions import ValidationError as DjValidationError
from rest_framework.exceptions import ValidationError as DRFValidationError
from rest_framework.views import api_settings
from rest_framework.views import exception_handler as drf_exception_handler

DRF_NON_FIELD_ERRORS = api_settings.NON_FIELD_ERRORS_KEY


def handle(exc, context):
 # translate django validation error which ...
 # .. causes HTTP 500 status ==&gt; DRF validation which will cause 400 HTTP status
 if isinstance(exc, DjValidationError):
 data = exc.message_dict
 if DJ_NON_FIELD_ERRORS in data:
 data[DRF_NON_FIELD_ERRORS] = data[DJ_NON_FIELD_ERRORS]
 del data[DJ_NON_FIELD_ERRORS]

 exc = DRFValidationError(detail=data)

 return drf_exception_handler(exc, context)
</code></pre>
and add this exception handler function as your default exception handler on django rest framework settings on your <code>settings.py</code> file
<pre><code class="lang-py">REST_FRAMEWORK = {
 # .....
 'EXCEPTION_HANDLER': 'path_to_your_exception_hander'
 # ...
}
</code></pre>
Now, the internal Django validation error that you raise from models or anywhere maybe will look like this;
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1646840847549/3BFL9mI8f.png" alt="error-400-bad-request.png" />
Tested on
<ul>
<li>Django(3.0.3) and Django Rest Framework(3.11.0)</li>
<li>Django(4.0.2) and Django Rest Framework(3.13.1)</li>
</ul>

While working with Django+Django Rest Framework, you might have come up in a problem that occurrence of Errors/ValidationErrors from Django Model or some internals will not response a valid json your API consumer was expecting.
For example:
Errors/ValidationErrors from Django Model or some internals will output something like

This looks so ugly (on debug mode only!),  but with DEBUG=False as well, you will get something like

So, let's create up a custom exception handler for Django Rest Framework which will catch exceptions from those above mentioned scenarios and convert them to something much more prettier which can be easily transformed to json  
from django.core.exceptions import NON_FIELD_ERRORS as DJ_NON_FIELD_ERRORS
from django.core.exceptions import ValidationError as DjValidationError
from rest_framework.exceptions import ValidationError as DRFValidationError
from rest_framework.views import api_settings
from rest_framework.views import exception_handler as drf_exception_handler

DRF_NON_FIELD_ERRORS = api_settings.NON_FIELD_ERRORS_KEY


def handle(exc, context):
    # translate django validation error which ...
    # .. causes HTTP 500 status ==> DRF validation which will cause 400 HTTP status
    if isinstance(exc, DjValidationError):
        data = exc.message_dict
        if DJ_NON_FIELD_ERRORS in data:
            data[DRF_NON_FIELD_ERRORS] = data[DJ_NON_FIELD_ERRORS]
            del data[DJ_NON_FIELD_ERRORS]

        exc = DRFValidationError(detail=data)

    return drf_exception_handler(exc, context)

and add this exception handler function as your default exception handler on django rest framework settings on your settings.py file
REST_FRAMEWORK = {
     # .....
    'EXCEPTION_HANDLER': 'path_to_your_exception_hander'
     # ...
}

Now, the internal Django validation error that you raise from models or anywhere maybe will look like this;

Tested on
Django(3.0.3) and Django Rest Framework(3.11.0)
Django(4.0.2) and Django Rest Framework(3.13.1)

Convert Django Validation Errors to DRF compatible Errors

When creating a web application you will come up with a need to have some sort of mechanism to store your data permanently either on a filesystem or a Database. For this  article/tutorial we will have a look inside storing your data on a Database. Da...

When creating a web application you will come up with a need to have some sort of mechanism to store your data permanently either on a filesystem or a Database. For this  article/tutorial we will have a look inside storing your data on a Database. Database is an organized collection of data for easy write/read. There are many databases available freely to use but we will focus on RDBMS supported by Django under the hood.
Django Models
Django model is the single, definite source of information about your data
It contains the essential fields and behaviors of the data you're storing
Django model is some sort of your Database table representation a db table --> a django model
We write django models on a class based style i.e using Python Class syntax. So, Each model is a Python class that subclassed django.db.models.Model
Each attributes(valid DB type) of the model represents a database field 
With all this, Django gives us an automatically generated database access API that let's us create, retrieve, update and delete objects using ORM. Thus, you hardly need to write any raw SQL. SQL stands for Structured Query Language used to communicate with a Database
This doesn't mean Django uses some sorts of magic to communicate with a Database. Under the hood Django create raw SQL for every operations(basically CRUD) to communicate with a Database
Django models lies inside models.py file on your Django apps. Each Django app can have multiple models/tables inside a models.py
Don't get confused with models.py and Model class we are talking. models.py is a python file which is inside every Django apps and Model Class is a Python class we create inside the models.py file
Basic Example of a Django Model
Lets take an example of User model which has username, first_name, last_name,  attributes/field
under your models.py, let's create our first model as follows,
from django.db import models

# we need to create a class which subclasses django.db.models.Model
# so let's create a class which inherits models.Model
class User(models.Model): 
        username = models.CharField(max_length=50)
        first_name = models.CharField(max_length=30)
        last_name = models.CharField(max_length=30)

Note,
Each field is specified as class attributes, and each attributes maps to a database column
Creating attributed like age=10 will not be reflected in our Database since Django will not know how to process it and map to a database column. This means, we need to use attribute type provided by Django only. (Advanced: You can create your own fields as well, but trust me fields provided by Django will be enough for nearly all field types you will ever need)
The model class we just created will create a database table like this; 
CREATE TABLE app_user(
          "id" serial NOT NULL PRIMARY KEY,
          "username" varchar(30) NOT NULL,
          "first_name" varchar(30) NOT NULL,
          "last_name" varchar(30) NOT NULL,
);


Don't get confused on how to generate this SQL, we need some commands to create a intermediate file (called migrations) which we will apply to our database (called migrate)
This is really awesome, we didn't write a single line of SQL, but we got the corresponding SQL statement to create our table. But,
we didn't add id attribute/field on our Model class, but this is included on the SQL, this is because Django will automatically add a Primary Key as id by default. Don't worry we can always customize this behavior but let's leave Django upon itself to do this good work 
we created our Model class as User but the SQL seems to have created app_user table, this is because on default behavior, django will craft a table name for your automatically based on your app name and Model class name. In our case, let's assume we create a django app as app and our Model class as User, so this means django will create app_user table. This behavior can be customized by overriding the Model class Meta information
Before jumping on commands to reflect our Django Model class to our database, let's first configure our database settings so that Django can use it and do the hard work.
Databases in Django
Django officially supports
PostgreSQL  (will need PostgreSQL>=9.5 and python package psycopg2>=2.5.4). psycopg2 is a PostgreSQL adapter for Python programming language
MariaDB (added in Django 3.0. Django supports MariaDB>=10.1)
MySQL (MySQL>=5.7 for Django 3.2  and required python adapter mysqlclient>=1.3.12)
Oracle (oracle>=12.12 and cx_oracle>=6.0 python driver required)
SQlite (SQlite>=3.8.3)
SQlite is a file based database. You don't need any Python adapters to work with SQlite database, since SQlite module is integrated into python itself. This means, to work with SQlite database, just write python code using sqlite3 module. Due to this reason Django will work under the hood with SQlite Database without any special environment setups. 
Since, working with SQlite initially to learn is pretty easy we will configure SQlite in our Project. Don't worry, integrating other databases is easy as well which we will focus on other articles.
By default, when creating a django project, under settings.py Django configures your Project to work with SQlite
# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

Notes;
ENGINE refers to the corresponding database backends/code/mappings for our preferred Database
We can add multiple database configurations inside this settings. Multiple database are used for data replication, optimization, aggregating data from multiple sources e.t.c, whose configurations might look like,
DATABASES = {
  'default': {
      'ENGINE': 'django.db.backends.sqlite3',
      'NAME': BASE_DIR / 'db.sqlite3',
  },
 'read_replica': {
      'ENGINE': 'django.db.backends.sqlite3',
      'NAME': BASE_DIR / 'db_replica.sqlite3',
  },
  'analytics_db': {
      'ENGINE': 'django.db.backends.sqlite3',
      'NAME': BASE_DIR / 'analytics_db.sqlite3',
  }
}



When connecting to other databases special/extra connection parameters will be required, let's take an example of PostgreSQL
DATABASES = {
  'default': {
      'ENGINE': 'django.db.backends.postgresql',
      'NAME': 'db_name',
      'USER': 'db_user',
      'PASSWORD': 'db_password',
      'HOST': '127.0.0.1',
      'PORT': '5432',
  }
}



So we checked our configurations and now let's head to the actual process of reflecting our Model Class to our Database as a Database table
Django Migrations (Migration framework)
Migrations are Django's way of propagating changed you make to your models into your database table
available commands:
python manage.py makemigrations responsible for creating new migrations based on changes you made to your models. This is an intermediate Python file django created before taking changes to the actual database server. Think of migration file as a history tracker (GIT) for your models. You create migrations after you make any changes to the models which should reflect to your database. Migrations files are created and placed under your apps migrations folder
python manage.py migrate responsible to pick the created migrations files and to peform apply/unapply operations which gets reflected to your database.
python manage.py sqlmigrate [app_name] [migration_file_name] which displays SQL statements for the migrations created using makemigrations command
python manage.py showmigrations which lists project's migrations and their status (i.e if it is applied to database or not)
So, the rule of thumb is first your create your migrations by using python manage.py makemigrations command and then apply those changes to database with python manage.py migrate
Reminder: Did you perform makemigrations and migrate command?
Model Field Options
Model field options are the options we can pass to individual model attribute classes. In previous example when we used models.CharField we used max_length option to tell django that the field should only have data lenght of upto given max_length. 
There are more options that we can pass to our model attributes depending upon our requirements, some of commonly used model options are:
null(default=False) when not provided it defaults to False, i.e: null value is not allowed
blank(default=False)
db_column used to create/customize column name on the Database table which if not provided defaults to the attribute name
default (used to provide default value to the attribute incase a value is not provided when adding a new object/row to a model/table). default can be a constant value or a callable object like python functions, this python function should return a value which can be used a default value for the attribute
unique(default=False) if true the field value must be unique throughout the table
validators a list of validators to run for this field
A simple example of Model using different model options
from django.db import models

def dummy_default_extra_data():
    return "Additional Information and data"

class DummyModel(models.Model):
    first_name = models.CharField(max_length=50)

    # assume, middle_name can be null
    middle_name = models.CharField(max_length=50, blank=True, null=True)

    last_name = models.CharField(max_length=50)

    # date_of_birth is long so create a dob for column name,
    # but, use date_of_birth inside django
    date_of_birth = models.DateTimeField(db_column='dob')

    # assume, email_notification is allowed by default
    email_notification = models.BooleanField(default=True)

    # extra_data default as a function,
    # (you can't use lambda function here)
    extra_data = models.TextField(default=dummy_default_extra_data)

    # assume, passport_number should be unique
    passport_number = models.CharField(max_length=100,unique=True)

ORM (Object Relational Mapper)
ORM Helps us write queries(simple or advanced) using object oriented paradigm of your favourite programming language 
Django ORM helps us to communicate with our database without using any SQL commands.
Abstract away the database system, so switching from MySQL to PostgreSQL is pretty easy
For now, to practice ORM(communicate with DB) we will not create any views or any complicated python code, instead we will use a shell provided by Django to run our ORM code. This django shell is an advance version of a Normal Python shell but Django modules are already loaded inside this shell.
You can open django shell using command python manage.py shell
For now, lets assume a simple model, we will use this model to understand ORM code
from django.db import models

class Information(models.Model):
        name = models.CharField(max_length=50)
        age = models.IntegerField()
        is_active = models.BooleanField(default=False)

Once, you have created your models django provides you with a default Manager called objects through which you can you can perform database operations. You can always customize or add more Managers to your models which we will see in future articles.
Don't forget, we will be getting familiar with ORM inside django shell for now. So open up the django shell
Creating Objects/ Adding row to DB table
save() method
   # assuming Information model belongs to practice app 
   from practice.models import Information 

   obj = Information()
   obj.name = "John"
   obj.age = 15
   obj.save()



create() method
  # assuming Information model belongs to practice app 
  from practice.models import Information 

  obj = Information.objects.create(name = "John")



Retrieving objects / get row/s from DB table
get() a single row. Can return/work with only single row/object
  # assuming Information model belongs to practice app 
  from practice.models import Information

  john_obj =  Information.objects.get(name="John")

  # will throw error if no row matched or multiple row is matched. 

  # get a object with non existing row to see the error
  check_error = Information.objects.get(name="Nothing")



all() to retrieve all rows from table, which returns an iterable queryset which can be looped to retrive every objects
  # assuming Information model belongs to practice app 
  from practice.models import Information

  queryset = Information.objects.all() # actual ORM

  for obj in queryset:
        print(obj, obj.name, obj.age)



filter() to retrive multiple rows (a queryset) but with certain filters/ SQL where statement
 # assuming Information model belongs to practice app 
 from practice.models import Information

 # get all objects/rows with age=15
 queryset = Information.objects.filter(age=15)

  for obj in queryset:
        print(obj, obj.name, obj.age)



Updating objects/ update rows of DB table
single update/ single row update
     # first get the object which you want to update

     # lets get the John and update his age to 20
     obj = Information.objects.get(name="John")
     obj.age = 20 # update age
     obj.save()



Multiple objects/rows update at once
   # lets update every rows to is_active=True 
   updated = Information.objects.all().update(is_active=True)
   print(updated)



Deleting a object/ a row from DB table
Single object delete/ single row delete
    # first get a object, and delete

    # lets delete John
    john_obj = Information.objects.get(name="John")
    john_obj.delete()



Multiple objects/rows delete at once
 # delete every objects from DB
 deleted = Information.objects.all().delete()

 # delete every rows whose is_active=False
 deleted = Information.objects.filter(is_active=False).delete()



Raw SQL
When working sometimes you may need to perform raw SQL instead of the ORM. This can come up when you need to write advanced SQL, or maybe use some native DB feature which Django ORM doesn't support or maybe the raw SQL is pretty fast than the ORM, whatever can be the reason and its really accepted to write raw SQL as well, but i suggest to stick to ORM as much as possible.
raw() which maps to models attributes automatically
 data = Information.objects.raw(
                "SELECT id,name,age FROM practice_information"
             )



You can also perform SQL directly,
    from django.db import connection

    with connection.cursor() as cursor:
             cursor.execute("SELECT * FROM practice_information;")
             rows = cursor.fetchall()
             print(rows)

Whats next?
In the next article we will see more about the models relations/DB table relationship and advance guides on lookups and QuerySet

Django Models Part I (Database Setup,  Models and ORM)

When working with web frameworks at some point rendering data directly through your controller or views is not efficient. Let's take an example of code snippet from our first article in this series Django Setup, Architecture and Hello World which loo...

When working with web frameworks at some point rendering data directly through your controller or views is not efficient. Let's take an example of code snippet from our first article in this series <a target="_blank" href="/django-setup-architecture-and-hello-world">Django Setup, Architecture and Hello World</a> which looks like
<pre><code>from django.http import HttpResponse


def hi_view(request):
 response = """
 &lt;html&gt;
 &lt;body&gt;
 &lt;h1&gt;Hello world&lt;/h1&gt;
 &lt;/body&gt;
 &lt;/html&gt;
 """
 return HttpResponse(response)
</code></pre>Here we trying to send whole bunch of HTML code from the views itself. This might look easy and so clean to see in this example but trust me as your project grows up and when you will have 100's and 1000's of HTML code this method will be pain and unmanageable. 
So how do we write templates in a manageable way and make it dynamic as well? The answer is through the help of <code>Template System</code> provided by the framework.
<h3 id="django-template">Django Template</h3>
<ul>
<li>A template can have some static HTML parts and some dynamic content to be inserted in between the HTML</li>
<li>A very efficient and convenient way of generating HTML dynamically</li>
<li>Django has built-in backend for its own template system which is called <code>Django Template Language (DTL)</code> and also for the popular alternative <code>Jinja2</code></li>
</ul>
<blockquote>
For the sake of simplicity we will be using <code>Django Template Language (DTL)</code> which is preconfigured on <code>settings.py</code> when creating our project using <code>django-admin</code> command line utility <code>i.e: django-admin startproject project_name</code> 
You may have already heard about <code>Jinja</code> if you are from the <code>Flask</code> background. Let me know through <code>RFA form or comments</code> if i should make some tutorial on <code>Jinja</code>
</blockquote>
<h3 id="so-where-are-template-engine-configured">So where are template engine configured?</h3>
If you open up your <code>settings.py</code> file or if you followed me through <a target="_blank" href="/django-setup-architecture-and-hello-world">Django Setup, Architecture and Hello World</a> then you will find your <code>settings.py</code> file under <code>meme/settings.py</code> since we created <code>meme</code> django project you will see something like
<pre><code>TEMPLATES = [
 {
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': [os.path.join(BASE_DIR, 'templates')]
 ,
 'APP_DIRS': True,
 'OPTIONS': {
 # .... many options here ...
 },
 },
]
</code></pre>You can see <code>BACKEND</code> key which points to dotted path for <code>DjangoTemplates</code> and other settings there like <code>DIRS</code> where the template engine will look for the html files
<h3 id="lets-get-to-know-last-checklist-before-we-jump-in">Let's get to know last checklist before we jump in</h3>
<ul>
<li>To pass any value <code>(some dynamic contents like blog post, user info fetched from the DB e.t.c)</code> from view <code>(view function)</code> to the template <code>(html files)</code> we pass it as <code>context</code>. </li>
<li><code>Context</code> means a plain <code>dictionary</code> of key and value <code>(K:V)</code> i.e <code>{'name':'John'}</code></li>
<li>You can always provide as much template directory on your <code>settings.py</code> under <code>TEMPLATEs</code>--&gt;<code>DIRS</code></li>
<li>Since <code>APP_DIRS=True</code> in our above settings, the template finder will search inside our <code>INSTALLED_APPS</code>--&gt;<code>templates/</code> folder as well.</li>
<li>So this means, you can add your templates under the directory provided in <code>DIRS</code> or under <code>templates/</code> directory under your <code>app folder</code></li>
</ul>
<blockquote>
So, where should i actually put my <code>HTML files</code>? The simple answer is if your <code>HTML file</code> is is for local app use only then put it inside <code>templates/</code> folder of your apps or else if the <code>HTML file</code> is used globally in all your apps then put it under the <code>DIRS</code> folder which is usually <code>templates/</code> folder inside your project directory
</blockquote>
<h3 id="loading-and-rendering-a-template">Loading and rendering a template</h3>
First let's create a simple template under our <code>DIRS</code> directory or under <code>templates/</code> inside our app.
To make it more clear, lets create a new app named <code>smile</code> through help of dango command <code>python manage.py startapp smile</code> and register this app to the <code>settings.py</code> file and as soon as you register your app create <code>templates</code> folder inside your app and create a <code>HTML file</code> <code>smile.html</code>
<blockquote>
We created a new app, so do you remember as soon as we create a new app we need to add this to the <code>INSTALLED_APPS</code> on our <code>settings.py</code> file
</blockquote>
Under your <code>smile/templates/smile.html</code> or if create any <code>HTML file</code> you like.
<pre><code> &lt;html&gt;
 &lt;body&gt;
 &lt;h1&gt;Today's special joke&lt;/h1&gt;
 &lt;h1&gt; {{ joke }}&lt;/h1&gt;
 &lt;/body&gt;
 &lt;/html&gt;
</code></pre>But, whats the <code>{{ joke }}</code> thing inside this <code>HTML file</code>. This is a way to insert dynamic content to the <code>HTML file</code>. This dynamic content or values are sent from <code>views</code> in the form of <code>context</code> we talked earlier
<blockquote>
If your template doesn't have any dynamic contents to be inserted then that's fine as well, many of your page can have a static HTML as well
</blockquote>
So, lets use and render this templates <code>create a view function</code>
<pre><code># views.py
from django.http import HttpResponse
from django.template import loader


def joke_view(request):
 # load the template that you just created 
 template = loader.get_template(template_name='smile.html') 

 # create context
 context = {
 'joke': 'This is really funny joke !!'
 }

 result = template.render(context, request)
 return HttpResponse(result)
</code></pre>Now, quickly create up a URL path for this view functions like we did on our previous tutorial and you should see something like this when you visit your URL
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1624114690872/2uovuaCXn.png" alt="django-template-and-context-initial-preview.png" />
<h3 id="but-wait-there-are-shortcuts-for-easy-rendering-of-templates">But wait, there are shortcuts for easy rendering of templates</h3>
The <code>view function joke_view()</code> we just created can also be written as 
<pre><code>from django.shortcuts import render


def joke_view(request):
 # create context
 context = {
 'joke': 'This is really funny joke !!'
 }
 return render(request, 
 template_name="smile.html", 
 context=context)
</code></pre><h3 id="more-on-context-rendering-and-working-with-templates">More on Context rendering and working with Templates</h3>
<h4 id="variables">Variables</h4>
<ul>
<li>Outputs/prints the value from the context</li>
<li>Variables are surrounded by <code>{{ }}</code> <code>(just like we did it just above)</code></li>
</ul>
<h5 id="examples">Examples</h5>
Lets assume HTML template to be <code>Hi, i am from {{ location }} and i love {{ lang }}.</code>
So,
<ul>
<li><code>context={'location':'Earth','lang':'Python'}</code> on this HTML template would render to <code>Hi, i am from Earth and i love Python.</code></li>
<li><code>context={'location':'Mars','lang':'Javascript'}</code> on this HTML template would render to <code>Hi, i am from Mars and i love Javascript.</code></li>
</ul>
<h4 id="tags">Tags</h4>
<ul>
<li>A tag can be used to output content</li>
<li>It can be used to perform control structure <code>i.e: if/else, loops</code></li>
<li>It can do many things to make your template dynamic</li>
<li>Tags are surrounded by <code>{% %}</code></li>
<li>Some tags require ending tags where as some doesn't need it<ul>
<li><code>{% csrf_token %}</code> has no ending tag</li>
<li><code>{% if user.is_authenticated %}Hello, {{ user.username }}.{% endif %}​</code> has ending tag</li>
</ul>
</li>
</ul>
<h5 id="examples">Examples</h5>
<ul>
<li><code>for</code> loops over each item in an array<pre><code>{% for language in language_list %}
 &lt;li&gt;{{ language }}&lt;/li&gt;
{% endfor %}
</code></pre> where <code>language_list</code> is a iterable sent from view function as a context</li>
<li><code>if</code>
<pre><code class="lang-html">{% if language_list %}
 Number of language: {{ language_list|length }}
{% else %}
 &lt;h1&gt;No Languages found.&lt;/h1&gt;
{% endif %}
</code></pre>
 it even supports <code>elif</code> don't forget to try it
</li>
<li><code>now</code> displays current date and/or time<pre><code> It is {% now "jS F Y H:i" %}
</code></pre></li>
</ul>
<h4 id="filters">Filters</h4>
<ul>
<li>Filter transform the values of variables and tag arguments</li>
</ul>
<h5 id="examples">Examples</h5>
<ul>
<li><code>add</code> adds the arguments to the value<pre><code>{{ number|add:"10" }}
</code></pre> would output 100 if the value of number is 90. The value of number is sent as context 
 from the view function as <code>context={'number':90}</code></li>
<li><code>capfirst</code> capitalizes the first character of the value<pre><code> {{ name|capfirst }}
</code></pre></li>
<li><code>default</code> provides a default value if existing value evaluates to False<pre><code> {{ country|default:"Not Selected" }}
</code></pre> If country is empty <code>"" (empty string)</code> then output will be Not Selected</li>
</ul>
<h4 id="comments">Comments</h4>
<ul>
<li>Comments are placed in <code>{# #}</code> which are not rendered on templates during rendering process</li>
</ul>
<h5 id="examples">Examples</h5>
<pre><code class="lang-html">{# this is a comment and will not be rendered #}
</code></pre>
<h3 id="last-note">Last Note</h3>
We looked into <code>tags</code> and <code>filters</code> and saw some examples. I tried to make it easy as possible and lastly want to let you know there are so many builtin tags and filters inside django. Please have a look into official django docs <a target="_blank" href="https://docs.djangoproject.com/en/3.2/ref/templates/builtins/">https://docs.djangoproject.com/en/3.2/ref/templates/builtins/</a> to see the complete list.
<blockquote>
You can always create your own template tags and filter, trust me they make working with templates very easy
</blockquote>

When working with web frameworks at some point rendering data directly through your controller or views is not efficient. Let's take an example of code snippet from our first article in this series Django Setup, Architecture and Hello World which looks like
from django.http import HttpResponse


def hi_view(request):
 response = """
 <html>
 <body>
 <h1>Hello world</h1>
 </body>
 </html>
 """
 return HttpResponse(response)

Here we trying to send whole bunch of HTML code from the views itself. This might look easy and so clean to see in this example but trust me as your project grows up and when you will have 100's and 1000's of HTML code this method will be pain and unmanageable. 
So how do we write templates in a manageable way and make it dynamic as well? The answer is through the help of Template System provided by the framework.
Django Template
A template can have some static HTML parts and some dynamic content to be inserted in between the HTML
A very efficient and convenient way of generating HTML dynamically
Django has built-in backend for its own template system which is called Django Template Language (DTL) and also for the popular alternative Jinja2
For the sake of simplicity we will be using Django Template Language (DTL) which is preconfigured on settings.py when creating our project using django-admin command line utility i.e: django-admin startproject project_name 
You may have already heard about Jinja if you are from the Flask background. Let me know through RFA form or comments if i should make some tutorial on Jinja
So where are template engine configured?
If you open up your settings.py file or if you followed me through Django Setup, Architecture and Hello World then you will find your settings.py file under meme/settings.py since we created meme django project you will see something like
TEMPLATES = [
 {
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': [os.path.join(BASE_DIR, 'templates')]
 ,
 'APP_DIRS': True,
 'OPTIONS': {
 # .... many options here ...
 },
 },
]

You can see BACKEND key which points to dotted path for DjangoTemplates and other settings there like DIRS where the template engine will look for the html files
Let's get to know last checklist before we jump in
To pass any value (some dynamic contents like blog post, user info fetched from the DB e.t.c) from view (view function) to the template (html files) we pass it as context. 
Context means a plain dictionary of key and value (K:V) i.e {'name':'John'}
You can always provide as much template directory on your settings.py under TEMPLATEs-->DIRS
Since APP_DIRS=True in our above settings, the template finder will search inside our INSTALLED_APPS-->templates/ folder as well.
So this means, you can add your templates under the directory provided in DIRS or under templates/ directory under your app folder
So, where should i actually put my HTML files? The simple answer is if your HTML file is is for local app use only then put it inside templates/ folder of your apps or else if the HTML file is used globally in all your apps then put it under the DIRS folder which is usually templates/ folder inside your project directory
Loading and rendering a template
First let's create a simple template under our DIRS directory or under templates/ inside our app.
To make it more clear, lets create a new app named smile through help of dango command python manage.py startapp smile and register this app to the settings.py file and as soon as you register your app create templates folder inside your app and create a HTML file smile.html
We created a new app, so do you remember as soon as we create a new app we need to add this to the INSTALLED_APPS on our settings.py file
Under your smile/templates/smile.html or if create any HTML file you like.
 <html>
 <body>
 <h1>Today's special joke</h1>
 <h1> {{ joke }}</h1>
 </body>
 </html>

But, whats the {{ joke }} thing inside this HTML file. This is a way to insert dynamic content to the HTML file. This dynamic content or values are sent from views in the form of context we talked earlier
If your template doesn't have any dynamic contents to be inserted then that's fine as well, many of your page can have a static HTML as well
So, lets use and render this templates create a view function
# views.py
from django.http import HttpResponse
from django.template import loader


def joke_view(request):
 # load the template that you just created 
 template = loader.get_template(template_name='smile.html') 

 # create context
 context = {
 'joke': 'This is really funny joke !!'
 }

 result = template.render(context, request)
 return HttpResponse(result)

Now, quickly create up a URL path for this view functions like we did on our previous tutorial and you should see something like this when you visit your URL

But wait, there are shortcuts for easy rendering of templates
The view function joke_view() we just created can also be written as 
from django.shortcuts import render


def joke_view(request):
 # create context
 context = {
 'joke': 'This is really funny joke !!'
 }
 return render(request, 
 template_name="smile.html", 
 context=context)

More on Context rendering and working with Templates
Variables
Outputs/prints the value from the context
Variables are surrounded by {{ }} (just like we did it just above)
Examples
Lets assume HTML template to be Hi, i am from {{ location }} and i love {{ lang }}.
So,
context={'location':'Earth','lang':'Python'} on this HTML template would render to Hi, i am from Earth and i love Python.
context={'location':'Mars','lang':'Javascript'} on this HTML template would render to Hi, i am from Mars and i love Javascript.
Tags
A tag can be used to output content
It can be used to perform control structure i.e: if/else, loops
It can do many things to make your template dynamic
Tags are surrounded by {% %}
Some tags require ending tags where as some doesn't need it
{% csrf_token %} has no ending tag
{% if user.is_authenticated %}Hello, {{ user.username }}.{% endif %}​ has ending tag
Examples
for loops over each item in an array
{% for language in language_list %}
 <li>{{ language }}</li>
{% endfor %}

 where language_list is a iterable sent from view function as a context
if
{% if language_list %}
 Number of language: {{ language_list|length }}
{% else %}
 <h1>No Languages found.</h1>
{% endif %}

 it even supports elif don't forget to try it
now displays current date and/or time
 It is {% now "jS F Y H:i" %}



Filters
Filter transform the values of variables and tag arguments
Examples
add adds the arguments to the value
{{ number|add:"10" }}

 would output 100 if the value of number is 90. The value of number is sent as context 
 from the view function as context={'number':90}
capfirst capitalizes the first character of the value
 {{ name|capfirst }}


default provides a default value if existing value evaluates to False
 {{ country|default:"Not Selected" }}

 If country is empty "" (empty string) then output will be Not Selected
Comments
Comments are placed in {# #} which are not rendered on templates during rendering process
Examples
{# this is a comment and will not be rendered #}

Last Note
We looked into tags and filters and saw some examples. I tried to make it easy as possible and lastly want to let you know there are so many builtin tags and filters inside django. Please have a look into official django docs https://docs.djangoproject.com/en/3.2/ref/templates/builtins/ to see the complete list.
You can always create your own template tags and filter, trust me they make working with templates very easy

Django Templates, Context, Template Tags and filters

When a page is requested, Django under the hood created a HttpRequest object, this HttpRequest object contains meta information about the request.
This is the same request object we talked when we created our view function def profile_view(request):....

When a page is requested, Django under the hood created a <code>HttpRequest object</code>, this HttpRequest object contains meta information about the request.
This is the same request object we talked when we created our view function <code>def profile_view(request):...</code> (check type of request to confirm i.e <code>print(type(request)) # must be HttpRequest class</code>).
When a view function receives a HttpRequest object as its first argument, this view function must return and <code>HttpResponse object</code>.
A sample view,
<pre><code class="lang-py">def profile_view(request): # first parameter HttpRequest Object
 return HttpResponse("Hello World") # view returned HttpResponse Object
</code></pre>
<h3 id="heading-the-httprequest-object">The HttpRequest object</h3>
Many of us might just ignore this Request object thinking its of no use, but trust me there are lots of meta information about our request, which we may need 
in our program/view function to properly execute our logic.
Some of the attributes and methods of HttpRequest objects are:
<ol>
<li>HttpRequest.path (<code>request.path</code> in our view function, which give us path i.e: /profile/)</li>
<li>HttpRequest.path (<code>request.method</code> in our view function, which gives us Uppercase request method i.e: GET, POST, HEAD)</li>
<li>HttpRequest.GET (<code>request.GET</code> in our view function, which gives us all HTTP GET parameters in dict like object)</li>
<li>HttpRequest.POST (<code>request.POST</code> in our view function, which gives us all HTTP POST parameters in dict like object)</li>
<li>HttpRequest.FILES (<code>request. [Text](Link) FILES</code> in our view function, which gives us all uploaded files from HTML form in a dict like object)</li>
<li>HttpRequest.headers (<code>request.headers</code> in our view function, which gives us all HTTP headers in a dict like object)</li>
<li>HttpRequest.user (<code>request.user</code> in our view function, which gives us currently authenticated user. This attribute is set from middleware. We will look into this in later section of our series)</li>
</ol>
It consist of some useful methods as well i.e: <code>HttpRequest.get_host()</code> <code>HttpRequest.get_port()</code> <code>HttpRequest.is_secure() #https or not</code> which you can try and experiment yourself.
<h3 id="heading-the-httpresponse-object">The HttpResponse object</h3>
We learnt about HttpRequest object, which was automatically created by the Django itself and get passed to the view function. But on the other hand, its our duty as a programmer to return and <code>HttpResponse object</code> from view function like we did in previous example.
<pre><code class="lang-py">from django.http import HttpResponse

response = HttpResponse("Hello World")
</code></pre>
we can also add our content incrementally
<pre><code class="lang-py">response = HttpResponse()
response.write("hello ")
response.write("world")
</code></pre>
<h3 id="heading-jsonresponse-object">JsonResponse object</h3>
It is also possible to have a JSON encoded response. 
<pre><code class="lang-py">from django.http import JsonResponse

response = JsonResponse({"message":"Hi from djangotherightway.com"})
</code></pre>
<blockquote>
But, remember everything under the hood is a <code>HttpResponse()</code> 
</blockquote>
complete example,
<pre><code class="lang-py">from django.http import JsonResponse

def message_view(request):
 return JsonResponse({"message":"Hi from djangotherightway.com"})
</code></pre>
<blockquote>
if you want to serialize and response non-dict objects then make sure you include safe=False in JsonResponse <code>JsonResponse([1,2,3],safe=False)</code>
</blockquote>
<h3 id="heading-returning-404-errors-from-httpresponse">Returning 404 errors from HttpResponse</h3>
Every Http response must have a status code. 404 is one of the status code frequently used to denote that the requested page was not found
<pre><code class="lang-py">from django.http import HttpResponse, HttpResponseNotFound

def home_view(request):
 if some_condition:
 return HttpResponseNotFound("Page not found")
 else:
 return HttpResponse("Page found")
</code></pre>
<h4 id="heading-lets-take-some-examples">Let's take some examples</h4>
<ul>
<li>Finding our request method in our view function</li>
</ul>
<pre><code class="lang-py">def home_view(request):
 if request.method == 'GET':
 # do something for GET
 elif request.method == 'POST':
 # do something for POST here
 else:
 # fallback? or and error response?
</code></pre>
<ul>
<li>Returning custom HTTP status code</li>
</ul>
<pre><code class="lang-py">from django.http import HttpResponse

def home_view(request):
 if some_condition:
 return HttpResponse(status=403) # 403 means permission denied 
 else:
 return HttpResponse(status=200) # 200 means OK
</code></pre>
<h3 id="heading-but-what-are-http-status-code">But, what are Http status code?</h3>
<ul>
<li>Status code are some numbers issued by server in <code>response</code> to a client <code>request</code></li>
<li>Status code are divided up into five groups as follows where first digit refers to the category of the response<ul>
<li>1XX (informational response)</li>
<li>2XX (Successful)</li>
<li>3XX (Redirection)</li>
<li>4XX (Client error)</li>
<li>5XX (Server error)</li>
</ul>
</li>
<li>Examples;<ul>
<li>If server responds with status code <code>404</code> means it lies to <code>Client error</code> group and <code>404</code> means <code>Page Not Found</code></li>
<li>If server responds with status code <code>500</code> means it lies to <code>Server error</code> group and <code>500</code> means <code>Internal Server Error</code></li>
</ul>
</li>
</ul>
<blockquote>
Now being a backend engineer there lies a confusion, on how to select a status code. Actually this totally depends on the situation you are in and the requirements you are in(<code>has nothing to do with web framework or stacks you are working on</code>) but we always should follow a standard widely accepted by the community. Let's try to understand it more with an example;
<ul>
<li>Status code 3XX means <code>Redirection</code> category, to be more specific let's assume <code>308</code> status code which means <code>Permanent Redirection</code>. So to inform a client of a redirection you simply respond with a <code>308</code> status code and a <code>Location</code> to where the client should redirect. This way client simply performs a redirection because client knows the use case of <code>308</code> status code. But what is a client? Is't this a client side software created by engineers? So, it's a client side engineer duty to implement those, but what if we make changes on status code(<code>maybe 200 instead of 308</code>) to perform this same operation? This is also possible</li>
<li>To perform the same redirection work, now server will send <code>200</code> status code with some data <code>{'redirect_to':'https://djangotherightway.com'}</code>. This way on the client side we simply implement a logic where we check for <code>redirect_url</code> on <code>200 status</code> and implement redirection. On a JS client side you will redirect a user to other location using a simple code <code>window.location.replace("https://djangotherightway.com");</code></li>
</ul>
</blockquote>
So, does this mean we can use any status code for performing operations? The simple answer would be No, this is a suggestion only and my suggestion is <code>Let's follow standards to make our community much more stronger</code>, but what about the example i just explain above? Well, some case might arise up when you need to customize according to your need and may need to skip the standard but try to be on the standard as much as possible
<code>Standard Matters</code> because since <code>3XX</code> means a <code>redirection</code> have you ever noticed your browser will automatically redirect you to another location incase your browser gets <code>3XX</code>. Browser does this for making user experience good and doesn't mean browser will react on every status code they see from the server.
Do you want to see this browser behaviour in action? type <code>https://djangotherightway.com/learn</code> in the browser and you will be redirected to <code>https://djangotherightway.com/series/learn</code> all with the help of a simple status code <code>301</code> which means <code>Moved Permanently</code>

When a page is requested, Django under the hood created a HttpRequest object, this HttpRequest object contains meta information about the request.
This is the same request object we talked when we created our view function def profile_view(request):... (check type of request to confirm i.e print(type(request)) # must be HttpRequest class).
When a view function receives a HttpRequest object as its first argument, this view function must return and HttpResponse object.
A sample view,
def profile_view(request):             # first parameter HttpRequest Object
    return HttpResponse("Hello World") # view returned HttpResponse Object

The HttpRequest object
Many of us might just ignore this Request object thinking its of no use, but trust me there are lots of meta information about our request, which we may need 
in our program/view function to properly execute our logic.
Some of the attributes and methods of HttpRequest objects are:
HttpRequest.path (request.path in our view function, which give us path i.e: /profile/)
HttpRequest.path (request.method in our view function, which gives us Uppercase request method i.e: GET, POST, HEAD)
HttpRequest.GET  (request.GET in our view function, which gives us all HTTP GET parameters in dict like object)
HttpRequest.POST  (request.POST in our view function, which gives us all HTTP POST parameters in dict like object)
HttpRequest.FILES (request. [Text](Link) FILES in our view function, which gives us all uploaded files from HTML form in a dict like object)
HttpRequest.headers (request.headers in our view function, which gives us all HTTP headers in a dict like object)
HttpRequest.user (request.user in our view function, which gives us currently authenticated user. This attribute is set from middleware. We will look into this in later section of our series)
It consist of some useful methods as well i.e: HttpRequest.get_host() HttpRequest.get_port() HttpRequest.is_secure() #https or not which you can try and experiment yourself.
The HttpResponse object
We learnt about HttpRequest object, which was automatically created by the Django itself and get passed to the view function. But on the other hand, its our duty as a programmer to return and HttpResponse object from view function like we did in previous example.
from django.http import HttpResponse

response = HttpResponse("Hello World")

we can also add our content incrementally
response = HttpResponse()
response.write("hello ")
response.write("world")

JsonResponse object
It is also possible to have a JSON encoded response. 
from django.http import JsonResponse

response = JsonResponse({"message":"Hi from djangotherightway.com"})

But, remember everything under the hood is a HttpResponse() 
complete example,
from django.http import JsonResponse

def message_view(request):
  return JsonResponse({"message":"Hi from djangotherightway.com"})

if you want to serialize and response non-dict objects then make sure you include safe=False in JsonResponse JsonResponse([1,2,3],safe=False)
Returning 404 errors from HttpResponse
Every Http response must have a status code. 404 is one of the status code frequently used to denote that the requested page was not found
from django.http import HttpResponse, HttpResponseNotFound

def home_view(request):
    if some_condition:
        return HttpResponseNotFound("Page not found")
    else:
        return HttpResponse("Page found")

Let's take some examples
Finding our request method in our view function
def home_view(request):
    if request.method == 'GET':
        # do something for GET
    elif request.method == 'POST':
        # do something for POST here
    else:
        # fallback? or and error response?

Returning custom HTTP status code
from django.http import HttpResponse

def home_view(request):
    if some_condition:
        return HttpResponse(status=403) # 403 means permission denied 
    else:
        return HttpResponse(status=200) # 200 means OK

But, what are Http status code?
Status code are some numbers issued by server in response to a client request
Status code are divided up into five groups as follows where first digit refers to the category of the response
1XX (informational response)
2XX (Successful)
3XX (Redirection)
4XX (Client error)
5XX (Server error)
Examples;
If server responds with status code 404 means it lies to Client error group and 404 means Page Not Found
If server responds with status code 500 means it lies to Server error group and 500 means Internal Server Error
Now being a backend engineer there lies a confusion, on how to select a status code. Actually this totally depends on the situation you are in and the requirements you are in(has nothing to do with web framework or stacks you are working on) but we always should follow a standard widely accepted by the community. Let's try to understand it more with an example;
Status code 3XX means Redirection category, to be more specific let's assume 308 status code which means Permanent Redirection. So to inform a client of a redirection you simply respond with a 308 status code and a Location to where the client should redirect. This way client simply performs a redirection because client knows the use case of 308 status code. But what is a client? Is't this a client side software created by engineers? So, it's a client side engineer duty to implement those, but what if we make changes on status code(maybe 200 instead of 308) to perform this same operation? This is also possible
To perform the same redirection work,  now server will send 200 status code with some data {'redirect_to':'https://djangotherightway.com'}. This way on the client side we simply implement a logic where we check for redirect_url on 200 status and implement redirection. On a JS client side you will redirect a user to other location using a simple code window.location.replace("https://djangotherightway.com");
So, does this mean we can use any status code for performing operations? The simple answer would be No, this is a suggestion only and my suggestion is Let's follow standards to make our community much more stronger, but what about the example i just explain above? Well, some case might arise up when you need to customize according to your need and may need to skip the standard but try to be on the standard as much as possible
Standard Matters because since 3XX means a redirection have you ever noticed your browser will automatically redirect you to another location incase your browser gets 3XX. Browser does this for making user experience good and doesn't mean browser will react on every status code they see from the server.
Do you want to see this browser behaviour in action? type https://djangotherightway.com/learn in the browser and you will be redirected to https://djangotherightway.com/series/learn all with the help of a simple status code 301 which means Moved Permanently

Request and Response in Django

A clean URL is really important for a good quality web application. You can design your own URL style i.e url can contain / or - anything there is no any restriction but these are the things i follow (some examples),

/profile/<username>/ instead of ...

A clean URL is really important for a good quality web application. You can design your own URL style <code>i.e url can contain / or - anything</code> there is no any restriction but these are the things i follow (some examples),
<ol>
<li><code>/profile/&lt;username&gt;/</code> instead of <code>/profile/&lt;db_primary_key_id&gt;/</code> to view user profile</li>
<li><code>/hello-world/</code> instead of <code>/helloworld/</code></li>
<li><code>/accounts/change-password/</code> instead of <code>/profile/&lt;username&gt;/account/settings/change-password/</code> for accounts password change</li>
<li><code>/blogs/?page=1</code> instead of <code>/blogs/page-1/</code> for paginations.</li>
</ol>
<blockquote>
You can follow any pattern, but make it readable and consistent in your project
</blockquote>
<h3 id="heading-creating-a-url-on-django">Creating a URL on Django</h3>
To create a URL on Django you simple create a path and point that path to a view function like we did in previous turorials.
Here are some examples,
<pre><code class="lang-py">from django.urls import path

from profile.views import profile_view
from accounts.views import change_password_view

urlpatterns = [
 path('/profile/', profile_view),
 path('/accounts/change-password/',change_password_view)
]
</code></pre>
As you can see we use <code>path()</code> function to create our URLs. The path function take arguments where we define the path of url and the view function that it points.
<h3 id="heading-capturing-values-from-url">Capturing Values from URL</h3>
Let's assume a URL path <code>/profile/&lt;username&gt;/</code> here <code>&lt;username&gt;</code> part is dynamic and we need to capture this value on our URL and pass it to the view function.
For this purpose we use <code>Path Converters</code>. Django already provides us some path converters in default, they are: <code>str</code> <code>int</code> <code>slug</code> <code>uuid</code> <code>path</code>. A/c to the type we need, we can select a path converter and add it to the URL like below,
<pre><code class="lang-py"># urls.py
from django.urls import path

from profile.views import user_profile_detail_view

urlpatterns = [
 path('/profile/&lt;str:username&gt;/', user_profile_detail_view) # we used &lt;str&gt; path converter and assigned the value to username
]
</code></pre>
since we need to grab the captured <code>username</code> on our view function as well, we can write our view function as, 
<pre><code class="lang-py"># profile/views.py

def user_profile_detail_view(request, username): # we added username argument on our view function
 # print(type(username)) # do this for every path converters to see tha magic. i.e: using &lt;int&gt; converter would give you &lt;int&gt; type
 # get this username info from DB
 # prepare output
 # send output as HttpResponse
 ....
</code></pre>
<blockquote>
We can always create our own custom path converters if the default converters do not satisfy our need. 
</blockquote>
<h3 id="heading-using-regular-expressions-in-urls">Using regular expressions in URLs</h3>
Sometime we may need to use regular expression in our URL since everytime the simple <code>path()</code> wont satisfy our need.
To create regular expression on url path use <code>re_path()</code> instead of <code>path()</code>
<pre><code class="lang-py">from django.urls import path, re_path

from blog.views import all_blogs_for_year_view

urlpatterns = [
 re_path(r'^blogs/(?P&lt;year&gt;[0-9]{4})/$', all_blogs_for_year_view),
]
</code></pre>
<h3 id="heading-how-does-urlconf-work">How does URLconf work</h3>
Django consist of <code>ROOT_URLCONF</code> settings on your projects <code>settings.py</code> file. This is the one and only URL config file your django will look for. All urls in our project must be inside the defined <code>ROOT_URLCONF</code> file. You might come up with a question, There can be as many django apps in the project and they cna have their own urls, but if django can only look into the <code>ROOT_URLCONF</code> file, then how does our logic fit up. The answer is, you can have <code>n</code> numbers of URL files in your project, but through some way you need to integrate those urls on your <code>ROOT_URLCONF</code> file.
<blockquote>
If incoming Request Object has <code>urlconf</code> attribute set (this can be from middlewares), then django will use this instead of <code>ROOT_URLCONF</code>, but dont worry about it for now.
</blockquote>
Remember these things, 
<ol>
<li>in request <code>http://127.0.0.1:8000/profile/</code>, Django will look only <code>/profile/</code> in your URL configurations file</li>
<li>In request <code>http://127.0.0.1:8000/profile/?id=123</code>, Django will only <code>/profile/</code> in your URL configrations file</li>
<li>It doesn't look at the request method as well, All request methods. like <code>HEAD</code> <code>POST</code> <code>GET</code> will land to the same view function. You can from some way find the request method on your view function and perform the logic accordingly. i.e: <code>post method</code> on <code>/profile/</code> will update your profile but <code>get</code> on <code>/profile/</code> will display your profile information. We will look into this in later tutorials</li>
</ol>
<h3 id="heading-including-other-urlconfs">Including other URLconfs</h3>
As our project grows up, we split our <code>url</code> files or group them for readability. 
<pre><code class="lang-py">from django.urls import include, path
from profile.views import self_profile_view

extra_extra_url_patterns = [
 path("/me/",self_profile_view)
]

urlpatterns = [ # this is our main urlpattern list

 path("/profile/",include(extra_extra_url_patterns)) # include the patterns

 # this will create url ==&gt; /profile/ + /me/ from extra_extra_url_patterns = /profile/me/ is the final URL created

 # and you can also include, other urls.py file from your app 
 path("world/",include('world.urls')) 
 # you do not need to import world.urls as you can simply write the dotted path of your url file
 # so, this means, inside your world app, there will be urls.py file : world/urls.py
]
</code></pre>

A clean URL is really important for a good quality web application. You can design your own URL style i.e url can contain / or - anything there is no any restriction but these are the things i follow (some examples),
/profile/<username>/ instead of /profile/<db_primary_key_id>/ to view user profile
/hello-world/ instead of /helloworld/
/accounts/change-password/ instead of /profile/<username>/account/settings/change-password/ for accounts password change
/blogs/?page=1 instead of /blogs/page-1/ for paginations.
You can follow any pattern, but make it readable and consistent in your project
Creating a URL on Django
To create a URL on Django you simple create a path and point that path to a view function like we did in previous turorials.
Here are some examples,
from django.urls import path

from profile.views import profile_view
from accounts.views import change_password_view

urlpatterns = [
 path('/profile/', profile_view),
 path('/accounts/change-password/',change_password_view)
]

As you can see we use path() function to create our URLs. The path function take arguments where we define the path of url and the view function that it points.
Capturing Values from URL
Let's assume a URL path /profile/<username>/ here <username> part is dynamic and we need to capture this value on our URL and pass it to the view function.
For this purpose we use Path Converters. Django already provides us some path converters in default, they are: str int slug uuid path. A/c to the type we need, we can select a path converter and add it to the URL like below,
# urls.py
from django.urls import path

from profile.views import user_profile_detail_view

urlpatterns = [
 path('/profile/<str:username>/', user_profile_detail_view) # we used <str> path converter and assigned the value to username
]

since we need to grab the captured username on our view function as well, we can write our view function as, 
# profile/views.py

def user_profile_detail_view(request, username): # we added username argument on our view function
 # print(type(username)) # do this for every path converters to see tha magic. i.e: using <int> converter would give you <int> type
 # get this username info from DB
 # prepare output
 # send output as HttpResponse
 ....

We can always create our own custom path converters if the default converters do not satisfy our need. 
Using regular expressions in URLs
Sometime we may need to use regular expression in our URL since everytime the simple path() wont satisfy our need.
To create regular expression on url path use re_path() instead of path()
from django.urls import path, re_path

from blog.views import all_blogs_for_year_view

urlpatterns = [
 re_path(r'^blogs/(?P<year>[0-9]{4})/$', all_blogs_for_year_view),
]

How does URLconf work
Django consist of ROOT_URLCONF settings on your projects settings.py file. This is the one and only URL config file your django will look for. All urls in our project must be inside the defined ROOT_URLCONF file. You might come up with a question, There can be as many django apps in the project and they cna have their own urls, but if django can only look into the ROOT_URLCONF file, then how does our logic fit up. The answer is, you can have n numbers of URL files in your project, but through some way you need to integrate those urls on your ROOT_URLCONF file.
If incoming Request Object has urlconf attribute set (this can be from middlewares), then django will use this instead of ROOT_URLCONF, but dont worry about it for now.
Remember these things, 
in request http://127.0.0.1:8000/profile/, Django will look only /profile/ in your URL configurations file
In request http://127.0.0.1:8000/profile/?id=123, Django will only /profile/ in your URL configrations file
It doesn't look at the request method as well, All request methods. like HEAD POST GET will land to the same view function. You can from some way find the request method on your view function and perform the logic accordingly. i.e: post method on /profile/ will update your profile but get on /profile/ will display your profile information. We will look into this in later tutorials
Including other URLconfs
As our project grows up, we split our url files or group them for readability. 
from django.urls import include, path
from profile.views import self_profile_view

extra_extra_url_patterns = [
 path("/me/",self_profile_view)
]

urlpatterns = [ # this is our main urlpattern list

 path("/profile/",include(extra_extra_url_patterns)) # include the patterns

 # this will create url ==> /profile/ + /me/ from extra_extra_url_patterns = /profile/me/ is the final URL created

 # and you can also include, other urls.py file from your app 
 path("world/",include('world.urls')) 
 # you do not need to import world.urls as you can simply write the dotted path of your url file
 # so, this means, inside your world app, there will be urls.py file : world/urls.py
]

A clean URL is really important for a good quality web application. You can design your own URL style i.e url can contain / or - anything there is no any restriction but these are the things i follow (some examples),

/profile// instead of ...

URL designing and  URL kwargs in Django

Installing python
First of all, Python is required.
Python is high level, interpreted general purpose programming language.
Install Python on your system from Official Python Download 

We will not cover in depth about python in this series, but let ...

<h5 id="installing-python">Installing python</h5>
First of all, Python is required.
Python is high level, interpreted general purpose programming language.
Install Python on your system from <a target="_blank" href="https://www.python.org/downloads/">Official Python Download</a> 
<blockquote>
We will not cover in depth about python in this series, but let me know if i should (Will try to cover some basics in future updates)
</blockquote>
<h5 id="database-setup">Database Setup</h5>
As as web programmer, we will need some sort of database for persistant storage. Some might call, we could just use some sorts of caching for a small specific purpose web application but we will require a database sooner or later in the project. 
The good news is, we can skip this for now because Python already includes implementation of a lightweight database called SQLite.
You can know more about this File based database from <a target="_blank" href="https://www.sqlite.org/index.html">https://www.sqlite.org/index.html</a>. 
To learn about the Python API for SQLite DB go to <a target="_blank" href="https://docs.python.org/3/library/sqlite3.html">https://docs.python.org/3/library/sqlite3.html</a>. This includes tutorials to create a SQLite database and perform some database operations. 
<blockquote>
Don't worry for now about Database installation(MYSQL,POSTGRES,ORACLE) for Django. We will learn about it in another chapter of this series.
</blockquote>
<h5 id="installing-django">Installing Django</h5>
The easiest way to install django is through pip. pip is package installer for Python. If you are using python&gt;=3.4 then pip is automatically installed. Learn more about pip from <a target="_blank" href="https://en.wikipedia.org/wiki/Pip_(package_manager">Wikipedia</a>).
<ol>
<li>from your terminal <code>pip install django</code></li>
<li>Confirm installation from pip <code>pip list</code> [on the terminal]</li>
<li>Django installation will make django-admin command line utility available in your shell. <code>django-admin</code> [on the terminal] to check if its working</li>
</ol>
If everything worked fine in this steps, then we can be sure Django has been successfully installed, but we can confirm this installation from import statements as well.
On the Python shell [not on the terminal directly] <code>i.e: Shell that opens after you type python or python3 according to your installation on the system</code> do the following. If this runs without a problem, we can confirm that our Python interpreter can see the installed Django
<pre><code>import django
django.get_version()
</code></pre><h3 id="django">Django</h3>
<h5 id="creating-a-django-project">Creating a Django Project</h5>
For the sake of this series, we will assume a Project containing some specific features. Lets assume a project called <code>Meme</code>. This project simply allows user to upload Meme on the web application.
<code>django-admin startproject meme</code>
This will create a Django Project pre-configured to run instantly, which will create the following folders and files.
<pre><code>.
├── manage.py
└── meme
 ├── __init__.py
 ├── asgi.py
 ├── settings.py
 ├── urls.py
 └── wsgi.py

1 directory, 6 files
</code></pre>Django comes up with pre build/pre configured server for development purpose. You can run your development server using <code>python manage.py runserver</code>. This will run your django server on <code>8000</code> port on default. You can always configure this according to your need. When navigating to the django deployed address, which is usually <code>http://127.0.0.1:8000/</code> you will see the output 
<img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1623423319133/czsUAZKnCr.png" alt="djangoDefaultPage.png" />
<blockquote>
Congrats !!! Your Django is Up and Running
</blockquote>
<h5 id="django-apps">Django Apps</h5>
Django app is a Python Package which contains some features which can be reused in another project as well. For an example. (Completely Imaginary example)
<ol>
<li>Facebook is a project and (fb chat, fb groups, fb games) can be called application of this project. </li>
<li>Instagram is a project and (stories, IGTV) can be called application of this project.</li>
</ol>
So, a Django app is a smaller unit of the Django project which consist of some specific feature set. Trust me, dividing features under smaller apps is lot more effective in terms of readability and reusability.
<h5 id="creating-django-apps">Creating Django Apps</h5>
<code>python manage.py startapp [NAME_OF_APP]</code> 
so, in our case lets create a app named world in our existing project, just to demonstrate some <code>hello world</code>
<code>python manage.py startapp world</code> This would create some new files and folders in our project as follows, 
<pre><code>.
├── manage.py
├── meme
│ ├── __init__.py
│ ├── asgi.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── world
 ├── __init__.py
 ├── admin.py
 ├── apps.py
 ├── migrations
 │ └── __init__.py
 ├── models.py
 ├── tests.py
 └── views.py

3 directories, 13 files
</code></pre>After this is done, we need a last thing to be done so that our app is recognized by the Django Project. So, head over to <code>meme/settings.py</code> and add your newly created django app to the list of installed appps
<pre><code>INSTALLED_APPS = [
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',

 'world' # ===&gt;&gt; Add your newly created app here
]
</code></pre>Don't worry about the apps already being registered in the <code>INSTALLED_APPS</code>. Those apps are the most useful apps django has provided to us. For an example: <code>django.contrib.auth</code> provides us <code>DB table</code>,<code>signup</code>,<code>signin</code> features for our Users under the hood. This is actually what peoples mean to say when they talk about <code>Rapid Application Development in Django</code>. We can always customize this app according to our need, but trust me a <code>MVC</code> or <code>POC</code> project including some <code>Production application</code> would never need to customize these apps. This works perfectly !!!
<h5 id="creating-our-first-view">Creating our first view</h5>
Let's assume a URL <code>/hi/</code> would return a response <code>Hello World</code>. i.e: when users navigates to <code>http://127.0.0.1:8000/hi/</code> would output <code>hello world</code>
Open file, <code>world/views.py</code>
<pre><code>from django.http import HttpResponse


# create a function based view
# First parameter is a Django Request Object,
# so for convention we write request.
# We could have written just r or abcd instead of request in func parameter
def hi_view(request):
 response = HttpResponse() # create a Response Object
 response.content = "Hello world"
 return response

 # or this could be written as
 # return HttpResponse("hello world")
</code></pre>So, we created our first view. We now need a URL to be assigned to this view. i.e <code>/hi/</code> would point to <code>def hi_view(request):....</code>
Lets update our URLs from <code>meme/urls.py</code>. This is also our root url configuration. i.e: Django looks this file for URL configs
<blockquote>
You can view your root url config file registered in django from <code>ROOT_URLCONF</code> settings inside <code>meme/settings.py</code>
</blockquote>
<pre><code>from django.contrib import admin
from django.urls import path

# import our view function which is in world app
from world.views import hi_view

urlpatterns = [
 path('admin/', admin.site.urls),

 # create a URL path /hi/
 path('hi/', hi_view)
]
</code></pre>But wait, you can see a URL path <code>/admin/</code> already being registered when we created our project. Dont worry about it for now. We will see about it in upcoming part in this series.
So now, lets run our server and head over to <code>http://127.0.0.1:8000/hi/</code>. We can see the page displaying <code>hello world</code> which came from <code>hi_view function</code>
Lets add some HTML into our output so that we can display <code>hello world</code> formatted inside proper HTML tag
<pre><code>from django.http import HttpResponse


def hi_view(request):
 response = """
 &lt;html&gt;
 &lt;body&gt;
 &lt;h1&gt;Hello world&lt;/h1&gt;
 &lt;/body&gt;
 &lt;/html&gt;
 """
 return HttpResponse(response)
</code></pre>We might get confused looking this code thinking we will write every HTML inside this function. But in later section of this series we will learn to manage HTML templates of our project. So dont get confused for now.
<h5 id="managepy">manage.py</h5>
We used manage.py to run our server, create new apps, but what exactly is this manage.py ?
<code>manage.py</code> is a command line utility provided by Django to manage django project. We provide commands to the <code>manage.py</code> like <code>runserver</code>, <code>startapp</code>, <code>shell</code> and it runs the command script. The good news is we can create our own custom management commands as well.
If you want to navigate and deep dive, Have a look inside, <code>runserver</code> code from <a target="_blank" href="https://github.com/django/django/blob/master/django/core/management/commands/runserver.py#L24">Django Github Runserver Command</a>
<blockquote>
run <code>python manage.py</code> to see all available commands on your project
</blockquote>

Installing python
First of all, Python is required.
Python is high level, interpreted general purpose programming language.
Install Python on your system from Official Python Download 
We will not cover in depth about python in this series, but let me know if i should (Will try to cover some basics in future updates)
Database Setup
As as web programmer, we will need some sort of database for persistant storage. Some might call, we could just use some sorts of caching for a small specific purpose web application but we will require a database sooner or later in the project. 
The good news is, we can skip this for now because Python already includes implementation of a lightweight database called SQLite.
You can know more about this File based database from https://www.sqlite.org/index.html. 
To learn about the Python API for SQLite DB go to https://docs.python.org/3/library/sqlite3.html. This includes tutorials to create a SQLite database and perform some database operations. 
Don't worry for now about Database installation(MYSQL,POSTGRES,ORACLE) for Django. We will learn about it in another chapter of this series.
Installing Django
The easiest way to install django is through pip. pip is package installer for Python. If you are using python>=3.4 then pip is automatically installed. Learn more about pip from Wikipedia).
from your terminal pip install django
Confirm installation from pip pip list [on the terminal]
Django installation will make django-admin command line utility available in your shell. django-admin [on the terminal] to check if its working
If everything worked fine in this steps, then we can be sure Django has been successfully installed, but we can confirm this installation from import statements as well.
On the Python shell [not on the terminal directly] i.e: Shell that opens after you type python or python3 according to your installation on the system do the following. If this runs without a problem, we can confirm that our Python interpreter can see the installed Django
import django
django.get_version()

Django
Creating a Django Project
For the sake of this series, we will assume a Project containing some specific features. Lets assume a project called Meme. This project simply allows user to upload Meme on the web application.
django-admin startproject meme
This will create a Django Project pre-configured to run instantly, which will create the following folders and files.
.
├── manage.py
└── meme
 ├── __init__.py
 ├── asgi.py
 ├── settings.py
 ├── urls.py
 └── wsgi.py

1 directory, 6 files

Django comes up with pre build/pre configured server for development purpose. You can run your development server using python manage.py runserver. This will run your django server on 8000 port on default. You can always configure this according to your need. When navigating to the django deployed address, which is usually http://127.0.0.1:8000/ you will see the output 

Congrats !!! Your Django is Up and Running
Django Apps
Django app is a Python Package which contains some features which can be reused in another project as well.
For an example. (Completely Imaginary example)
Facebook is a project and (fb chat, fb groups, fb games) can be called application of this project. 
Instagram is a project and (stories, IGTV) can be called application of this project.
So, a Django app is a smaller unit of the Django project which consist of some specific feature set. Trust me, dividing features under smaller apps is lot more effective in terms of readability and reusability.
Creating Django Apps
python manage.py startapp [NAME_OF_APP] 
so, in our case lets create a app named world in our existing project, just to demonstrate some hello world
python manage.py startapp world This would create some new files and folders in our project as follows, 
.
├── manage.py
├── meme
│ ├── __init__.py
│ ├── asgi.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── world
 ├── __init__.py
 ├── admin.py
 ├── apps.py
 ├── migrations
 │ └── __init__.py
 ├── models.py
 ├── tests.py
 └── views.py

3 directories, 13 files

After this is done, we need a last thing to be done so that our app is recognized by the Django Project. So, head over to meme/settings.py and add your newly created django app to the list of installed appps
INSTALLED_APPS = [
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',

 'world' # ===>> Add your newly created app here
]

Don't worry about the apps already being registered in the INSTALLED_APPS. Those apps are the most useful apps django has provided to us. For an example: django.contrib.auth provides us DB table,signup,signin features for our Users under the hood. This is actually what peoples mean to say when they talk about Rapid Application Development in Django. We can always customize this app according to our need, but trust me a MVC or POC project including some Production application would never need to customize these apps. This works perfectly !!!
Creating our first view
Let's assume a URL /hi/ would return a response Hello World. i.e: when users navigates to http://127.0.0.1:8000/hi/ would output hello world
Open file, world/views.py
from django.http import HttpResponse


# create a function based view
# First parameter is a Django Request Object,
# so for convention we write request.
# We could have written just r or abcd instead of request in func parameter
def hi_view(request):
 response = HttpResponse() # create a Response Object
 response.content = "Hello world"
 return response

 # or this could be written as
 # return HttpResponse("hello world")

So, we created our first view. We now need a URL to be assigned to this view. i.e /hi/ would point to def hi_view(request):....
Lets update our URLs from meme/urls.py. This is also our root url configuration. i.e: Django looks this file for URL configs
You can view your root url config file registered in django from ROOT_URLCONF settings inside meme/settings.py
from django.contrib import admin
from django.urls import path

# import our view function which is in world app
from world.views import hi_view

urlpatterns = [
 path('admin/', admin.site.urls),

 # create a URL path /hi/
 path('hi/', hi_view)
]

But wait, you can see a URL path /admin/ already being registered when we created our project. Dont worry about it for now. We will see about it in upcoming part in this series.
So now, lets run our server and head over to http://127.0.0.1:8000/hi/. We can see the page displaying hello world which came from hi_view function
Lets add some HTML into our output so that we can display hello world formatted inside proper HTML tag
from django.http import HttpResponse


def hi_view(request):
 response = """
 <html>
 <body>
 <h1>Hello world</h1>
 </body>
 </html>
 """
 return HttpResponse(response)

We might get confused looking this code thinking we will write every HTML inside this function. But in later section of this series we will learn to manage HTML templates of our project. So dont get confused for now.
manage.py
We used manage.py to run our server, create new apps, but what exactly is this manage.py ?
manage.py is a command line utility provided by Django to manage django project. We provide commands to the manage.py like runserver, startapp, shell and it runs the command script. The good news is we can create our own custom management commands as well.
If you want to navigate and deep dive, Have a look inside, runserver code from Django Github Runserver Command
run python manage.py to see all available commands on your project

Django Setup, Architecture and  Hello World

<div class="medium-feed-item"><a href="https://python.plainenglish.io/21-python-libraries-that-quietly-do-the-work-youre-still-doing-by-hand-2a72b82798c5?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/1200/1*KTfPoJSTnYmzmHRz-NcDng.png" width="1200"></a>Writing Python taught me that the biggest jumps in productivity rarely come from learning more syntax. They come from finally discovering&#x2026;<a href="https://python.plainenglish.io/21-python-libraries-that-quietly-do-the-work-youre-still-doing-by-hand-2a72b82798c5?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

Writing Python taught me that the biggest jumps in productivity rarely come from learning more syntax. They come from finally discovering…
Continue reading on Python in Plain English »

21 Python Libraries That Quietly Do The Work You’re Still Doing By Hand

<div class="medium-feed-item"><a href="https://python.plainenglish.io/8-python-testing-mistakes-that-make-tests-feel-useless-95c02a54a81c?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/1536/1*QTapCSD4-JGSWyUqMwOt4A.png" width="1536"></a>A green test suite doesn&#x2019;t always mean a reliable application.<a href="https://python.plainenglish.io/8-python-testing-mistakes-that-make-tests-feel-useless-95c02a54a81c?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

A green test suite doesn’t always mean a reliable application.
Continue reading on Python in Plain English »

8 Python Testing Mistakes That Make Tests Feel Useless

<div class="medium-feed-item"><a href="https://python.plainenglish.io/i-looked-for-python-problems-people-actually-pay-to-solve-1ce6bb7bdab5?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/600/1*pxNCtdRNK4mYmbynwHvC2g.png" width="600"></a>The best opportunities were surprisingly ordinary<a href="https://python.plainenglish.io/i-looked-for-python-problems-people-actually-pay-to-solve-1ce6bb7bdab5?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

The best opportunities were surprisingly ordinary
Continue reading on Python in Plain English »

I Looked for Python Problems People Actually Pay to Solve

<div class="medium-feed-item"><a href="https://python.plainenglish.io/8-python-skills-that-prove-you-have-actually-shipped-real-systems-edd9e8fec92f?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/906/1*qCWFi5oDtjm3ogbMHpaLtA.png" width="906"></a><a href="https://python.plainenglish.io/8-python-skills-that-prove-you-have-actually-shipped-real-systems-edd9e8fec92f?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

Continue reading on Python in Plain English »

8 Python Skills That Prove You Have Actually Shipped Real Systems

<div class="medium-feed-item"><a href="https://python.plainenglish.io/from-beginner-python-to-professional-python-what-actually-changes-c11a0d73ae1a?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/1536/1*oZKHzRXYcjAGzB0Jl2Pzcg.png" width="1536"></a>You can write Python for years and still write beginner-level Python.<a href="https://python.plainenglish.io/from-beginner-python-to-professional-python-what-actually-changes-c11a0d73ae1a?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

You can write Python for years and still write beginner-level Python.
Continue reading on Python in Plain English »

From Beginner Python to Professional Python: What Actually Changes?

<div class="medium-feed-item"><a href="https://python.plainenglish.io/the-pandas-mistake-that-turns-a-fast-script-into-a-frozen-one-487fe163dce9?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/2600/0*L5RJxZPavlsDaE1q" width="6720"></a>Your code works fine on a thousand rows. Then someone hands you a million, and it just stops responding. Here is exactly why, with the fix.<a href="https://python.plainenglish.io/the-pandas-mistake-that-turns-a-fast-script-into-a-frozen-one-487fe163dce9?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

Your code works fine on a thousand rows. Then someone hands you a million, and it just stops responding. Here is exactly why, with the fix.
Continue reading on Python in Plain English »

The Pandas Mistake That Turns a Fast Script Into a Frozen One

<div class="medium-feed-item"><a href="https://python.plainenglish.io/the-python-job-market-split-in-two-most-advice-is-written-for-the-half-that-is-shrinking-84b7a6f8c61b?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/1536/1*51mQs_W_2qoq-wzD1lh_Lw.png" width="1536"></a>One half has a talent shortage measured in hundreds of thousands of open roles. The other half has a queue. Almost every article you have&#x2026;<a href="https://python.plainenglish.io/the-python-job-market-split-in-two-most-advice-is-written-for-the-half-that-is-shrinking-84b7a6f8c61b?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

One half has a talent shortage measured in hundreds of thousands of open roles. The other half has a queue. Almost every article you have…
Continue reading on Python in Plain English »

The Python Job Market Split in Two. Most Advice Is Written for the Half That Is Shrinking.

<div class="medium-feed-item"><a href="https://python.plainenglish.io/7-python-libraries-every-developer-should-know-before-2027-0c8c3a066145?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/1536/1*3mE0hZ-CMtfc82QsDtQsqg.png" width="1536"></a>The fastest way to get better at Python is not memorizing more syntax. It is learning how to make Python do work that you would otherwise&#x2026;<a href="https://python.plainenglish.io/7-python-libraries-every-developer-should-know-before-2027-0c8c3a066145?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

The fastest way to get better at Python is not memorizing more syntax. It is learning how to make Python do work that you would otherwise…
Continue reading on Python in Plain English »

7 Python Libraries Every Developer Should Know Before 2027

<div class="medium-feed-item"><a href="https://python.plainenglish.io/the-python-library-everyone-should-know-and-almost-nobody-talks-about-b69cbe30f77f?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/902/1*__MdQcH2H-JdDB6wY9o8WA.png" width="902"></a>Your terminal has been capable of this the whole time. You just never had the right tool.<a href="https://python.plainenglish.io/the-python-library-everyone-should-know-and-almost-nobody-talks-about-b69cbe30f77f?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

Your terminal has been capable of this the whole time. You just never had the right tool.
Continue reading on Python in Plain English »

The Python Library Everyone Should Know And Almost Nobody Talks About

<div class="medium-feed-item"><a href="https://python.plainenglish.io/three-python-libraries-that-quietly-replaced-my-old-toolkit-in-2026-d63f44708c9d?source=rss----78073def27b8---4"><img src="https://cdn-images-1.medium.com/max/2600/0*OQuLuXtMsKuPHgHb" width="6000"></a>Not another recycled list of Pandas and Requests. These are the tools that actually changed how I write Python this year.<a href="https://python.plainenglish.io/three-python-libraries-that-quietly-replaced-my-old-toolkit-in-2026-d63f44708c9d?source=rss----78073def27b8---4">Continue reading on Python in Plain English »</a></div>

Not another recycled list of Pandas and Requests. These are the tools that actually changed how I write Python this year.
Continue reading on Python in Plain English »

Three Python Libraries That Quietly Replaced My Old Toolkit in 2026

Stop letting bot traffic evict your customers' sessions. A simple Redis configuration switch from LRU to LFU solved our crawler problem, with a Django configuration example.

<div class="w-block-html block-html">
 <iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="400" referrerpolicy="strict-origin-when-cross-origin" src="https://www.youtube.com/embed/lSNdp7qpqVo?si=dtY_d8ah_hTV6LM8" title="YouTube video player" width="750">
 </iframe>
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 We've seen a dramatic increase in malicious AI/web crawlers with our clients.
 
 
 These crawlers aren't honoring things like
 <code>
 robots.txt
 </code>
 or headers to indicate a page shouldn't be 
crawled (think links to facets like those in search results) that cause crawlers to get lost in a web of mostly 
useless or duplicated content.
 
 
 On top of that annoyance they're making tens if not
 
 hundreds of requests per second
 
 for hours at a time.
 
 
 These sites are reasonably fast and in many cases are behind awesome cache systems like Cloudflare, so 
why is it impacting our clients negatively?
 
 
 
 User sessions!
 
 These bots are creating thousands of new sessions that push the real human user's sessions out of the cache.
 
 
 We're using
 <a href="https://docs.djangoproject.com/en/dev/topics/http/sessions/">
 Django's Sessions
 </a>
 , but this 
technique works for any browser session token where you want to retain the sessions of real human 
users for as long as possible and expire out these robotic sessions.
 
 <h2>
 Let's talk about sessions
 </h2>
 
 Our default Django site template defaults to using the
 <code>
 cached_db
 </code>
 backend. This tries to get the session from 
Django's default cache (redis in most cases), if it's not found it is retrieved from the database and stored in the 
cache for the next request.
 
 
 Because of these asshole crawlers we've had to rethink this default and instead only keep the session in a cache 
for some of our customers.
 
 
 On most sites it doesn't really matter if the session data is retained. The worst case being the user is forced to log in again.
 
 
 With other sites, the user's session is absolutely crucial to the business. A simple example is we have e-commerce clients 
who want to provide a nice experience to their users. They want a random Internet user to be able to add items to their 
cart over time and only make them login to actually checkout.
 
 
 You need a session for that and you need that session to persist in cache for a reasonable amount of time.
 
 <h2>
 Default Redis
 </h2>
 
 By default Redis will use as much memory as possible and not expire keys that have a TTL set, but when it can no longer store keys in 
RAM it will fail to allow you to create a new session. This often causes whatever session system you're using to raise an exception 
and your site is broken.
 
 
 LRU (Least Recently Used) cache expiration is probably the most commonly known way to expire data. It's
 <a href="https://docs.python.org/3/library/functools.html#functools.lru_cache">
 built into Python
 </a>
 and it is the default for systems like memcached. You could configure or customize your session 
handling to use an LRU mechanism to keep RAM usage under control, but then you still have a problem.
 
 
 When you get a half million bogus AI requests in an hour and you only have RAM to hold say half of that, your real human 
customer who painstakingly curated the perfect cart of high dollar premium widgets but had the audacity to take a break to make 
dinner returns to their browser to find an empty cart and a fresh session.
 
 
 And unless you have a monopoly on widgets, they're likely to take their business elsewhere. I mean, if you can't keep my cart for an hour
why would I trust you with more complicated things like widget manufacturing and shipping logistics!?!?
 
 <h2>
 LFU to the Rescue
 </h2>
 
 I didn't know this until recently but Redis can be configured in a "volatile" mode which causes it to remove items even if the 
keys have TTLs on them. Redis provides
 <a href="https://redis.io/docs/latest/develop/reference/eviction/#eviction-policies">
 several options here
 </a>
 one of which is
 <code>
 volatile-lru
 </code>
 which is what most people would probably choose.
 
 
 However, what we really need here is LFU (Least Frequently Used)! Let me explain.
 
 
 Each of these bots generates a new session and uses it exactly once. This means that any regular human user who 
browses around a couple of pages will see their session remain for far longer. Frequent users, such as the website staff, 
likely would never have their session expire if not for the TTL.
 
 
 To illustrate this a bit I used an LLM to help me quickly generate a
 <a href="https://github.com/revsys/lfu-redis-example">
 demo of LRU vs LFU expiration in Redis
 </a>
 .
 
 
 The demo shows how we can keep shoving single use session keys into a Redis configured for LFU and retain our sessions which are 
used as little as a second time.
 
 <h2>
 Configuring Redis for LFU
 </h2>
 
 To adjust Redis for LFU you need to adjust your
 <code>
 redis.conf
 </code>
 with these three parameters:
 
 <div class="codehilite">
 <pre><code>maxmemory 9mb
maxmemory-policy volatile-lfu 
lazyfree-lazy-eviction yes
</code></pre>
 </div>
 
 This constrains Redis to use at most 9MBs of memory. Obviously you're going to want more session storage than that, so 
adjust it to as much RAM as makes sense for your situation. The next two turn on LFU even if the key has a TTL set (volatile) 
and tells Redis to expire keys asynchronously rather than blocking during the expiration.
 
 
 To do this in Docker Compose is fairly easy as well. You just need to write your own config and load it like this:
 
 <div class="codehilite">
 <pre><code>redis-lfu:
 image: "redis:8.2-alpine"
 command: redis-server /usr/local/redis/redis.conf
 ports:
 - "6001:6379"
 init: true
 stop_signal: SIGKILL
 volumes:
 - ./docker/redis-lfu.conf:/usr/local/redis/redis.conf:ro
</code></pre>
 </div>
 <h2>
 Configuring Django Sessions for LFU
 </h2>
 
 I ran into something I didn't think about when configuring Redis this way for a customer and want to point it out so you 
don't make the same mistake. Many Django sites use Redis and the Django cache for other things and NOT just sessions.
 
 Celery is one good example of where this can go wrong. In that case, we actually deploy two small Redis instances
one configured "normally" and one configured for LFU specifically for user sessions.
 
 
 So our local compose has services like this:
 
 <div class="codehilite">
 <pre><code> redis:
 image: "redis:8.2-alpine"
 ports:
 - "6000:6379"
 init: true
 stop_signal: SIGKILL

 redis-sessions:
 image: "redis:8.2-alpine"
 command: redis-server /usr/local/redis/redis.conf
 ports:
 - "6001:6379"
 init: true
 stop_signal: SIGKILL
 volumes:
 - ./docker/redis-lfu.conf:/usr/local/redis/redis.conf:ro
</code></pre>
 </div>
 
 Obviously you'll need to do something slightly different in Kubernetes or however you're ultimately deploying 
your production applications.
 
 
 And our Django settings cache and session changes look like this:
 
 <div class="codehilite">
 <pre><code># Define two different caches
CACHES = {
 "default": {
 "BACKEND": "django.core.cache.backends.redis.RedisCache",
 "LOCATION": f"redis://redis:6379/0",
 },
 "sessions": {
 "BACKEND": "django.core.cache.backends.redis.RedisCache",
 "LOCATION": f"redis://redis-sessions:6379/0",
 },
}

# Use cached sessions and specifically the LFU configured "sessions" cache 
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS = "sessions"
</code></pre>
 </div>
 
 Hopefully knowing that Redis can support LFU key expiration proves helpful to you!
 
 
 P.S. Dear AI/web bot crawlers, can we chat? I know you're in a hurry&mdash;gathering that 
big heap of data for your 'research' or racing to meet your boss's deadline&mdash;but maybe 
honor robots.txt? Or at least keep it to one request at a time?
 
 
 The Internet might hate you less. Hell, we might even say something nice about your new 
cryptocurrency or whatever.
 
 </div>
</div>

maxmemory 9mb
maxmemory-policy volatile-lfu 
lazyfree-lazy-eviction yes

redis-lfu:
  image: "redis:8.2-alpine"
  command: redis-server /usr/local/redis/redis.conf
  ports:
    - "6001:6379"
  init: true
  stop_signal: SIGKILL
  volumes:
    - ./docker/redis-lfu.conf:/usr/local/redis/redis.conf:ro

  redis:
    image: "redis:8.2-alpine"
    ports:
      - "6000:6379"
    init: true
    stop_signal: SIGKILL

  redis-sessions:
    image: "redis:8.2-alpine"
    command: redis-server /usr/local/redis/redis.conf
    ports:
      - "6001:6379"
    init: true
    stop_signal: SIGKILL
    volumes:
      - ./docker/redis-lfu.conf:/usr/local/redis/redis.conf:ro

# Define two different caches
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": f"redis://redis:6379/0",
    },
    "sessions": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": f"redis://redis-sessions:6379/0",
    },
}

# Use cached sessions and specifically the LFU configured "sessions" cache 
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS = "sessions"

  
  
   Hopefully knowing that Redis can support LFU key expiration proves helpful to you!
  
  
   P.S. Dear AI/web bot crawlers, can we chat? I know you're in a hurry—gathering that 
big heap of data for your 'research' or racing to meet your boss's deadline—but maybe 
honor robots.txt? Or at least keep it to one request at a time?
  
  
   The Internet might hate you less. Hell, we might even say something nice about your new 
cryptocurrency or whatever.

Sometimes LFU > LRU

At REVSYS, our first attempt at adding JSON-LD to our sites relied on embedding the data in the Django template. For the most part, this has worked fine, and we've had good results from an SEO perspective. But in terms of maintainability, it has not been the most efficient approach. We have now started transitioning to generating the structured data using Django Ninja and Pydantic. As a result, we now have cleaner templates and better maintainability.

Boosting SEO with Django Ninja, Pydantic, and JSON-LD

Writing Django management commands can involve a ton of boilerplate code. But Revsys uses two libraries that cut our management command code in half while making it more readable and powerful: django-click and django-typer.

# management/commands/load_movies_django.py
import json
from pathlib import Path

from django.conf import settings
from django.core.management.base import BaseCommand

from movies.utils import clear_movie_data, load_movies_from_data


class Command(BaseCommand):
    help = "Load movies data from JSON file into the database."

    def add_arguments(self, parser):
        parser.add_argument(
            "--file", default="data/movies.json", help="Path to movies JSON file"
        )
        parser.add_argument(
            "--clear", action="store_true", help="Clear existing data before loading"
        )
        parser.add_argument(
            "count", type=int, nargs="?", help="Number of movies to load (optional)"
        )

    def handle(self, *args, **options):
        if options["clear"]:
            self.stdout.write(self.style.WARNING("Clearing existing movie data..."))
            clear_movie_data()
            self.stdout.write(self.style.SUCCESS("Existing data cleared."))

        file_path = Path(settings.BASE_DIR) / options["file"]

        if not file_path.exists():
            self.stdout.write(self.style.ERROR(f"Error: File {file_path} not found"))
            return

        self.stdout.write(self.style.NOTICE(f"Loading movies from {file_path}..."))

        with open(file_path) as f:
            movies_data = json.load(f)

        count = options["count"]
        if count is not None:
            movies_data = movies_data[:count]
            self.stdout.write(self.style.NOTICE(f"Loading first {count} movies..."))

        total_created_movies, total_created_genres, total_created_cast = (
            load_movies_from_data(movies_data)
        )

        self.stdout.write(self.style.SUCCESS("\nLoading complete!"))
        self.stdout.write(self.style.SUCCESS(f"Created {total_created_movies} movies"))
        self.stdout.write(self.style.SUCCESS(f"Created {total_created_genres} genres"))
        self.stdout.write(
            self.style.SUCCESS(f"Created {total_created_cast} cast members")
        )

pip install django-click

# management/commands/load_movies_click.py
import djclick as click
from django.conf import settings

from movies.utils import clear_movie_data, load_movies_from_data


@click.command()
@click.option("--file", default="data/movies.json", help="Path to movies JSON file")
@click.option("--clear", is_flag=True, help="Clear existing data before loading")
@click.argument("count", type=int, required=False)
def command(file, clear, count):
    """Load movies data from JSON file into the database."""

    if clear:
        click.secho("Clearing existing movie data...", fg="yellow")
        clear_movie_data()
        click.secho("Existing data cleared.", fg="green")

    file_path = Path(settings.BASE_DIR) / file

    if not file_path.exists():
        click.secho(f"Error: File {file_path} not found", fg="red", err=True)
        return

    click.secho(f"Loading movies from {file_path}...", fg="blue")

    with open(file_path) as f:
        movies_data = json.load(f)

    if count is not None:
        movies_data = movies_data[:count]
        click.secho(f"Loading first {count} movies...", fg="cyan")

    total_created_movies, total_created_genres, total_created_cast = (
        load_movies_from_data(movies_data)
    )

    click.secho("\nLoading complete!", fg="green", bold=True)
    click.secho(f"Created {total_created_movies} movies", fg="green")
    click.secho(f"Created {total_created_genres} genres", fg="green")
    click.secho(f"Created {total_created_cast} cast members", fg="green")

import djclick as click
from myapp.models import User

@click.command()
@click.argument('user', type=click.ModelInstance(User))
def command(user):
    """Do something with a user."""
    click.echo(f"Processing user: {user.username}")

# Lookup by username field
@click.argument('user', type=click.ModelInstance(User, lookup='username'))

pip install django-typer

from django_typer.management import Typer
app = Typer(help="Load movies data from JSON file into the database.")

@app.command()
def main(
    count: int | None = typer.Argument(None, help="Number of movies to load"),
    file: str = typer.Option("data/movies.json", help="Path to movies JSON file"),
    clear: bool = typer.Option(False, help="Clear existing data before loading"),
):
    if clear:
        typer.secho("Clearing existing movie data...", fg=typer.colors.YELLOW)
        clear_movie_data()
        typer.secho("Existing data cleared.", fg=typer.colors.GREEN)

    file_path = Path(settings.BASE_DIR) / file

    if not file_path.exists():
        typer.secho(f"Error: File {file_path} not found", fg=typer.colors.RED, err=True)
        raise typer.Exit(1)

    typer.secho(f"Loading movies from {file_path}...", fg=typer.colors.BLUE)

    with open(file_path) as f:
        movies_data = json.load(f)

    total_created_movies, total_created_genres, total_created_cast = (
        load_movies_from_data(movies_data)
    )

    typer.secho("\nLoading complete!", fg=typer.colors.GREEN, bold=True)

def main(count: int = None, file: str = "data/movies.json", clear: bool = False):

from rich.console import Console
from rich.panel import Panel
from rich.progress import Progress, SpinnerColumn, TextColumn
from rich.table import Table

app = Typer(help="Load movies data from JSON file into the database.")

@app.command()
def main(
    # same function definition as before
):
    """Load movies data from JSON file into the database."""
    console = Console()

    # Display a pretty welcome banner
    console.print(Panel.fit("🎬 Movie Database Loader", style="bold blue"))

    with open(file_path) as f:
        movies_data = json.load(f)

    if count is not None:
        movies_data = movies_data[:count]
        console.print(f"🔢 Loading first [bold yellow]{count}[/bold yellow] movies...")

    # Add a progress bar
    with Progress(console=console) as progress:
        task = progress.add_task("🎭 Processing movies...", total=len(movies_data))
        total_created_movies, total_created_genres, total_created_cast = (
            load_movies_from_data(movies_data)
        )
        progress.update(task, completed=len(movies_data))

    # Add a table to summarize the output
    table = Table(title="📊 Loading Summary", style="green")
    table.add_column("Category", style="cyan", no_wrap=True)
    table.add_column("Count", style="magenta", justify="right")
    table.add_column("Icon", justify="center")

    table.add_row("Movies", str(total_created_movies), "🎬")
    table.add_row("Genres", str(total_created_genres), "🎭")
    table.add_row("Cast Members", str(total_created_cast), "👥")

    console.print()
    console.print(table)

# Load movies data into database
load-fresh-movie-data:
    just load-genres --clear 1000
    just load-people --clear 1000
    just load-movies --clear 1000

load-genres *args:
    docker compose exec web python manage.py load_genres {{args}}

load-people *args:
    docker compose exec web python manage.py load_people {{args}}

load-movies *args:
    docker compose exec web python manage.py load_movies {{args}}

  
  
   This pattern lets you create shortcuts for your management commands, and link them together.
  
  
   My honest take
  
  
   I use django-click for most of the management commands I need to write. It's clean, fast to write, and gets out of my way. But when I need to build something that helps me understand complex data or provides structured feedback during long-running operations, django-typer is the better choice.
  
  
   The next time you need to write a management command, try one of these libraries and let me know what you think!

Better Django management commands with django-click and django-typer

Stop link rot before users ever see it: this guide shows how one lightweight app scans your models, flags broken URLs, and slots neatly into any Django workflow.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 Most Django projects store some sort of URLs. Whether it's in a
 <code>
 URLField()
 </code>
 on 
some of your models or deep in some
 <code>
 TextField()
 </code>
 s full of HTML.
 
 
 We all know
 <a href="https://www.w3.org/Provider/Style/URI">
 cool URLs don't change
 </a>
 , but 
not all URLs are cool and some rot over time. How do you find out which of your links 
have disappeared on you?
 
 
 Turns out there is a Django app for that named
 <a href="https://pypi.org/project/django-linkcheck/">
 django-linkcheck
 </a>
 . It will check your URLs on a schedule you set and give you a nice admin page to manage dealing with them.
 
 </div>
</div>
<div class="w-block-content block-content">
 
 
 <img alt="Screenshot of django-linkcheck admin page" class="richtext-image full-width" height="550" src="https://sfo2.digitaloceanspaces.com/revsys-com-prod-media/images/CleanShot_2025-05-29_at_09.55.26.width-800.png" width="800"/>
 
 
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 It helpfully gives you the status it received, links to recheck or ignore this item and quick 'Edit' links to take you right to the model object in question!
 
 
 It hasn't had a release for awhile, but I can confirm it works just fine with Django 
5.1.x. The docs are a bit sparse, so I stumbled around a little bit getting it to work. This post is here to save you from having to also stumble around in the dark.
 
 <h2>
 Install and Setup
 </h2>
 
 Installing the app is straight forward, you just add it to
 <code>
 INSTALLED_APPS
 </code>
 and 
include the special admin view in your main
 <code>
 urls.py
 </code>
 .
 
 
 It then needs to create it's own tables so run:
 
 <div class="codehilite">
 <pre><code>$ ./manage.py migrate 
</code></pre>
 </div>
 
 You then need to tell it which models and fields you want it to handle. The docs 
suggest you run:
 
 <div class="codehilite">
 <pre><code>$ ./manage.py linkcheck_suggest_config --model myapp.SomeModel &gt; myapp/linklinks.py
</code></pre>
 </div>
 
 Which is a great idea, but it's a bit broken actually. This generates something like:
 
 <div class="codehilite">
 <pre><code>from myapp.models import SomeModel

class SomeModelLinklist(Linklist):
 model = SomeModel
 url_fields = [myapp.SomeModel.url]
 ignore_empty = [myapp.SomeModel.url]
 object_filter = {"active": True}

linklists = {
 "SomeModel": SomeModelLinklist,
}
</code></pre>
 </div>
 
 It fails to import
 <code>
 Linklist
 </code>
 for one, but the larger issue is it leads you believe you
set the fields in the form
 <code>
 &lt;app&gt;.&lt;model&gt;.&lt;fieldname&gt;
 </code>
 when in fact it really needs to be 
just a list of modelfield strings. The correct version would be:
 
 <div class="codehilite">
 <pre><code>from linkcheck import Linklist # actually import Linklist
from myapp.models import SomeModel

class SomeModelLinklist(Linklist):
 model = SomeModel
 url_fields = ["url"] # list fields as strings 
 ignore_empty = ["url""]
 object_filter = {"active": True}

linklists = {
 "SomeModel": SomeModelLinklist,
}
</code></pre>
 </div>
 
 This could be very confusing to a first time user or newer Django developer, but don't 
let that stop you. It's a really nice app that solves a real world issue.
 
 <h2>
 Checking your links
 </h2>
 
 To actually check your URLs from your models you then need to run two commands:
 
 <div class="codehilite">
 <pre><code>$ ./manage.py findlinks 
</code></pre>
 </div>
 
 This populates linkcheck's tables with the TODO list of sorts.
 
 
 You can then
 
 actually check
 
 them with:
 
 <div class="codehilite">
 <pre><code>$ ./manage.py checklinks 
</code></pre>
 </div>
 
 
 NOTE:
 
 Both of these should be re-run periodically, perhaps via a cron job, based on 
your personal needs.
 
 
 If you have any broken links they should be visible and ready to handle at
 <code>
 /admin/linkcheck/
 </code>
 now.
 
 
 Check out the
 <a href="https://github.com/DjangoAdminHackers/django-linkcheck?tab=readme-ov-file#settings">
 README
 </a>
 for more information on how you can set this up including settings for how frequently you would like the links to be rechecked.
 
 
 Hopefully these small tips make it easier to start using this great Django app. Cheers!
 
 </div>
</div>

$ ./manage.py migrate 

$ ./manage.py linkcheck_suggest_config --model myapp.SomeModel > myapp/linklinks.py

from myapp.models import SomeModel

class SomeModelLinklist(Linklist):
    model = SomeModel
    url_fields = [myapp.SomeModel.url]
    ignore_empty = [myapp.SomeModel.url]
    object_filter = {"active": True}

linklists = {
    "SomeModel": SomeModelLinklist,
}

from linkcheck import Linklist   # actually import Linklist
from myapp.models import SomeModel

class SomeModelLinklist(Linklist):
    model = SomeModel
    url_fields = ["url"]   # list fields as strings 
    ignore_empty = ["url""]
    object_filter = {"active": True}

linklists = {
    "SomeModel": SomeModelLinklist,
}

$ ./manage.py findlinks 

$ ./manage.py checklinks 

  
  
   
    NOTE:
   
   Both of these should be re-run periodically, perhaps via a cron job, based on 
your personal needs.
  
  
   If you have any broken links they should be visible and ready to handle at
   
    /admin/linkcheck/
   
   now.
  
  
   Check out the
   
    README
   
   for more information on how you can set this up including settings for how frequently you would like the links to be rechecked.
  
  
   Hopefully these small tips make it easier to start using this great Django app.  Cheers!

Give Your Django Admin X‑Ray Vision—Automatic Dead‑Link Detection

The 4 Docker Sins Killing Your Python Productivity. You changed a single line of code and Docker has to rebuild everything! Dramatically improve both fresh builds and rebuilds when working in Docker.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 If you're waiting more than 10 seconds for your Docker rebuilds, you're wasting hours of your life!
 
 
 So that you keep reading, here are the results!
 
 <h2>
 Results
 </h2>
 <ul>
 <li>
 Fresh builds: 50s &rarr; 18s (2.7x faster)
 </li>
 <li>
 Rebuilds: 47s &rarr; 0.4s (117x faster)
 </li>
 <li>
 Adding dependencies: 50s &rarr; 6s (8x faster)
 </li>
 </ul>
 <h2>
 Overview
 </h2>
 
 We work with Python development teams of all sizes and levels of sophistication. One area where 
many teams struggle is optimizing their Docker image build times.
 
 
 I was reminded of this yesterday replying to a recent
 <a href="https://old.reddit.com/r/django/comments/1klljn8/too_many_installed_django_apps/">
 r/django reddit thread
 </a>
 where the author assumed they needed to break their Django monolith up into a few services to reduce 
their build time, which isn't accurate, but is a common mistaken assumption.
 
 
 There are a few small things you can do to
 
 dramatically
 
 reduce the amount of time it takes to 
build (and more importantly REBUILD) a Python or Django docker image.
 
 
 The TL;DR is you need to:
 
 <ul>
 <li>
 Only rebuild the dependency layer when your dependencies actually change
 </li>
 <li>
 Cache your PyPI downloads locally and in CI
 </li>
 <li>
 Switch to using uv which is stupid stupid fast
 </li>
 <li>
 Use a multi-stage build
 </li>
 </ul>
 
 If you're already doing all of those things, you can safely skip the rest of this post.
 
 <h2>
 Naive Approach
 </h2>
 
 The most common problem and impactful issue is not ordering the lines in your Dockerfile 
to only rebuild the layers that need to be rebuilt.
 
 
 Not having to do anything at all is the fastest thing there is! It's a one 
million percent improvement! 🤣
 
 
 Here is what many people start with:
 
 <div class="codehilite">
 <pre><code>FROM python:3.13-slim

RUN mkdir /code
WORKDIR /code

COPY . /code/

RUN pip install -r requirements.txt

# ... rest of lines ending in a `CMD` to run
</code></pre>
 </div>
 
 So what's wrong with this? Because every time you change ANYTHING in your git repository 
you're re-installing your pip dependencies.
 
 
 This is thankfully easy to resolve. Instead of the above, you should be doing this:
 
 <div class="codehilite">
 <pre><code>FROM python:3.13-slim

RUN mkdir /code
WORKDIR /code

# Copy just the requirements first 
COPY ./requirements.txt /code/requirements.txt 

# Install dependencies 
RUN pip install -r requirements.txt

# Copy in everything else 
COPY . /code/

# ... rest of lines ending in a `CMD` to run
</code></pre>
 </div>
 
 Now when you rebuild this image it will only need to perform the
 <code>
 pip install
 </code>
 step when there has actually been a change to
your
 <code>
 requirements.txt
 </code>
 !
 
 
 Dependencies change somewhat frequently, but no where near as frequently as you change code, docs, tests, and your README this
stops wasting time rebuilding that particular Docker layer on every single change.
 
 <h2>
 Caching the PyPI dependencies
 </h2>
 
 Ok so now we're only doing this when there is really something new to do. The next thing to do is not bother downloading all of 
these dependencies each and every time we build our Docker image. By default pip caches your downloads when using it locally, 
so this little optimization is overlooked. Python developers either assume it IS happening inside Docker or that it is hard 
or impossible to make it do so.
 
 <h3>
 Where does pip cache things?
 </h3>
 
 You can
 <a href="https://pip.pypa.io/en/latest/cli/pip_cache/">
 manage your pip cache
 </a>
 but the most useful thing is to simply know where 
this cache exists. So run
 <code>
 pip cache dir
 </code>
 (or
 <code>
 uv cache dir
 </code>
 if you're already using
 <code>
 uv
 </code>
 we'll talk about it more later). If you 
look into that directory hopefully you'll see a bunch of files.
 
 
 Now this is the cache on your HOST OS, not inside of Docker. There are a couple of ways to expose this into your Docker image, but it's much easier to just have your Docker daemon cache it for you.
 
 
 If you're using a default Python docker image, you're running in Debian and by default everything is running as the root user. FYI there are security implications to this and you look into running your code as another user non-root user, but that's a topic for another post.
 
 
 So for the
 <code>
 root
 </code>
 user on a Debian system this makes the pip and uv cache locations are going to be in
 <code>
 /root/.cache/
 </code>
 so we need to make a small change to your
 <code>
 RUN
 </code>
 that installs everything.
 
 
 Instead of:
 
 
 <code>
 RUN pip install -r requirements.txt
 </code>
 
 
 We need to use:
 
 <div class="codehilite">
 <pre><code>RUN --mount=type=cache,target=/root/.cache,id=pip \
 python -m pip install -r /code/requirements.txt
</code></pre>
 </div>
 
 This is instructing the Docker daemon to cache this folder with the id
 <code>
 pip
 </code>
 and it will then be reused across builds.
 
 <h3>
 What about in CI?
 </h3>
 
 Things are a bit harder in CI. Depending on what CI system you're using it's sometimes built in, sometimes you need to make configuration adjustments. In any case, the goal you're after here is that the
 <code>
 /root/.cache/
 </code>
 folder is preserved and reused across builds so that the 
downloads are cached between CI runs.
 
 
 You can read up on all of the details of to
 <a href="https://docs.docker.com/build/cache/optimize/">
 optimize Docker cache usage
 </a>
 in the Docker docs.
 
 <h2>
 Use uv
 </h2>
 
 If you're not familiar with
 <a href="https://docs.astral.sh/uv/">
 uv
 </a>
 it's a near drop-in replacement 
for pip from the folks at Astral who also brought us the great
 <code>
 ruff
 </code>
 linting and formatting tool and the soon to be beta
 <a href="https://github.com/astral-sh/ty">
 ty
 </a>
 type checker.
 
 
 For most things you just prefix your normal pip command with
 <code>
 uv
 </code>
 and it works as expected, 
just a
 
 HELL OF A LOT
 
 faster.
 
 
 Switching to
 <code>
 uv
 </code>
 and adding in the cache mount makes our example Dockerfile now look like
this:
 
 <div class="codehilite">
 <pre><code>FROM python:3.13-slim

RUN mkdir /code
WORKDIR /code

# Install uv 
RUN --mount=type=cache,target=/root/.cache,id=pip \
 python -m pip install uv 

# Copy just the requirements first 
COPY ./requirements.txt /code/requirements.txt 

# Run uv pip install with caching! 
RUN --mount=type=cache,target=/root/.cache,id=pip \
 uv pip install --system -r /code/requirements.txt

# Copy in everything else 
COPY . /code/

# ... rest of lines ending in a `CMD` to run
</code></pre>
 </div>
 <h2>
 So how fast is it now?
 </h2>
 
 Things are quite a bit faster at the small expensive of a slightly more complicated
 <code>
 Dockerfile
 </code>
 .
 
 
 Naive Fresh - 50 seconds
 
 
 Naive Rebuild - 47 seconds.
 
 
 The difference here is just the speed of downloading the pip dependencies between runs.
 
 
 After we've fixed things to only re-run
 <code>
 pip install
 </code>
 when those requirements change gives us 
the biggest benefit.
 
 
 Naive Fixed Fresh - 50 seconds
 
 
 Naive Fixed Rebuild -
 
 10 seconds
 
 
 <h3>
 With Caching
 </h3>
 
 Caching our downloads improves our situation even further!
 
 
 Cached Fresh - 44 seconds
 
 
 Cached Rebuild -
 
 0.4 seconds
 
 
 <h3>
 With Caching and uv
 </h3>
 
 UV Fresh - 18.5 seconds
 
 
 UV Rebuild -
 
 0.4 seconds
 
 
 
 Why isn't
 <code>
 uv
 </code>
 faster? Well it IS faster downloading the files initially, I'm guessing it is doing something in parallel better or just being written in 
rust is making this aspect twice as fast as normal pip. But for these last two we're really just testing how faster Docker is able to 
create the layer since there is really no calls to pip or uv going on.
 
 <h2>
 Adding a new pip dependency into the mix
 </h2>
 
 The
 
 real speed up
 
 is when you need to add a new dependency. In our original requirements.txt we neglected to add the very useful
 <code>
 django-debug-toolbar
 </code>
 package. So I added it and re-ran all of these.
 
 <h3>
 Naive
 </h3>
 
 Naive Fresh - 50 seconds
 
 
 Naive Rebuild - 47 seconds.
 
 
 Naive Rebuild w/ new dependency -
 
 50 seconds
 
 
 
 Naive Fixed Fresh - 50 seconds
 
 
 Naive Fixed Rebuild - 10 seconds
 
 
 Naive Fixed Rebuild w/ new dependency -
 
 51 seconds
 
 
 <h3>
 With Caching
 </h3>
 
 Cached Fresh - 44 seconds
 
 
 Cached Rebuild - 0.4 seconds
 
 
 Cached Rebuild w/ new dependency -
 
 24 seconds
 
 
 <h3>
 With Caching and uv
 </h3>
 
 UV Fresh - 18.5 seconds
 
 
 UV Rebuild - 0.4 seconds
 
 
 UV Rebuild w/ new dependency -
 
 6 seconds
 
 
 
 So we went from a consistent 50ish seconds per build to 18 seconds for a fresh build, 6 seconds when adding a new dependency and 
nearly instant for rebuilds with no dependency changes.
 
 <h2>
 Bonus info
 </h2>
 <h3>
 Multi-stage Docker Builds with Python
 </h3>
 
 What are multi-stage builds? In short, they are
 <code>
 Dockerfile
 </code>
 s with multiple
 <code>
 FROM
 </code>
 lines.
 
 
 Why would I want to do that? Well size and security mainly.
 
 
 On the security front, using a multi-stage build allows you to deploy an image that does not include any 
compilers or build tools, but still use those tools to build the dependencies you use. In terms of size,
the your final image only includes the initial runtime environment, your built dependencies, but not any of 
the tools or dev packages needed to build those dependencies.
 
 
 So you get a smaller and more secure image, which are good things and they add just a
 
 BIT
 
 more complexity to 
your Dockerfile. Once you've been walked through it, it should be fairly clear.
 
 <div class="codehilite">
 <pre><code>FROM python:3.13-slim AS builder-py

RUN mkdir /code
WORKDIR /code

# Install uv 
RUN --mount=type=cache,target=/root/.cache,id=pip \
 python -m pip install uv 

# Copy just the requirements first 
COPY ./requirements.txt /code/requirements.txt 

# Run uv pip install with caching! 
RUN --mount=type=cache,target=/root/.cache,id=pip \
 uv pip install --system -r /code/requirements.txt

FROM python:3.13-slim AS release 

# Copy our system wide installed pip dependencies from builder-py
COPY --from=builder-py /usr/local /usr/local

# Copy in everything else 
COPY . /code/

# ... rest of lines ending in a `CMD` to run
</code></pre>
 </div>
 <h3>
 Benchmark / Testing done here
 </h3>
 
 You can find the exact Docker files and bits I used to do this testing here in
 <a href="https://github.com/revsys/blog-faster-docker-builds">
 this repo
 </a>
 .
 
 
 I did this testing on a M4 Max MacBook Pro with 128GBs of RAM on a 1.2 Gbps fiber internet connection while catching up on 
watching some PyCon 2025 talks. I'm also using Orbstack which improves the overall performance of Docker on MacOS. Your 
results will almost certainly vary, but doing any of these steps will save you and your team time in your CI pipelines and 
when building images locally. The small differences in download speed or available CPU don't really matter, we aren't doing a
CPU heavy micro-benchmark here.
 
 
 Our time on this planet is short, too short to spend it waiting for Docker to needlessly rebuild images.
 
 
 Do yourself a favor a start using these tips now!
 
 </div>
</div>

FROM python:3.13-slim

RUN mkdir /code
WORKDIR /code

COPY . /code/

RUN pip install -r requirements.txt

# ... rest of lines ending in a `CMD` to run

FROM python:3.13-slim

RUN mkdir /code
WORKDIR /code

# Copy just the requirements first 
COPY ./requirements.txt /code/requirements.txt 

# Install dependencies 
RUN pip install -r requirements.txt

# Copy in everything else 
COPY . /code/

# ... rest of lines ending in a `CMD` to run

RUN --mount=type=cache,target=/root/.cache,id=pip \
    python -m pip install -r /code/requirements.txt

FROM python:3.13-slim

RUN mkdir /code
WORKDIR /code

# Install uv 
RUN --mount=type=cache,target=/root/.cache,id=pip \
    python -m pip install uv 

# Copy just the requirements first 
COPY ./requirements.txt /code/requirements.txt 

# Run uv pip install with caching! 
RUN --mount=type=cache,target=/root/.cache,id=pip \
    uv pip install --system -r /code/requirements.txt

# Copy in everything else 
COPY . /code/

# ... rest of lines ending in a `CMD` to run

FROM python:3.13-slim AS builder-py

RUN mkdir /code
WORKDIR /code

# Install uv 
RUN --mount=type=cache,target=/root/.cache,id=pip \
    python -m pip install uv 

# Copy just the requirements first 
COPY ./requirements.txt /code/requirements.txt 

# Run uv pip install with caching! 
RUN --mount=type=cache,target=/root/.cache,id=pip \
    uv pip install --system -r /code/requirements.txt

FROM python:3.13-slim AS release 

# Copy our system wide installed pip dependencies from builder-py
COPY --from=builder-py /usr/local /usr/local

# Copy in everything else 
COPY . /code/

# ... rest of lines ending in a `CMD` to run

  
  
   Benchmark / Testing done here
  
  
   You can find the exact Docker files and bits I used to do this testing here in
   
    this repo
   
   .
  
  
   I did this testing on a M4 Max MacBook Pro with 128GBs of RAM on a 1.2 Gbps fiber internet connection while catching up on 
watching some PyCon 2025 talks. I'm also using Orbstack which improves the overall performance of Docker on MacOS. Your 
results will almost certainly vary, but doing any of these steps will save you and your team time in your CI pipelines and 
when building images locally. The small differences in download speed or available CPU don't really matter, we aren't doing a
CPU heavy micro-benchmark here.
  
  
   Our time on this planet is short, too short to spend it waiting for Docker to needlessly rebuild images.
  
  
   Do yourself a favor a start using these tips now!

Faster Python Docker Builds

To kick off a semi-regular series of blog posts about useful Django apps, we start with some definitions

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h2>
 Introduction
 </h2>
 
 We'll be doing a semi-regular series of blog posts about various useful Django apps. However, it seemed like a good idea to lay some groundwork first. That will help us do a few things:
 
 <ul>
 <li>
 define
 <code>
 app
 </code>
 along with a few other similar terms, and get some namespace confusion out of the way
 </li>
 <li>
 understand the value, as a
 
 developer
 
 , of creating separate apps in your Django projects
 </li>
 <li>
 understand the value, as a
 
 developer
 
 or
 
 end-user
 
 of a Django project, of using separate apps (third-party or internally-created) in your Django projects
 </li>
 </ul>
 <h2>
 What is an App? Context matters.
 </h2>
 
 If you go to the Django home page, https://www.djangoproject.com, the blurb at the top says:
 
 Django makes it easier to build better web apps more quickly and with less code.
 
 Django is often described as a
 <a href="https://en.wikipedia.org/wiki/Web_framework">
 web application framework
 </a>
 or something that you use to create web applications (web apps). I've used this description myself. I have also purposefully distinguished between a
 <code>
 web app
 </code>
 and a
 <code>
 website
 </code>
 during a Django tutorial I taught. I've also written a
 <a href="https://www.revsys.com/tidbits/website-vs-web-app-hidden-complexities/">
 blog post
 </a>
 on that topic. So, if Django is used to BUILD web apps, why are we talking about apps IN Django? The context shifts a bit if you're looking at something built with Django from the outside vs. from the inside.
 
 <h2>
 A View From The Inside
 </h2>
 
 From the outside, the specific nomenclature is much less important. But from the inside, as someone building something with Django, the specific terminology has more meaning. But, it can still be a little confusing.
 
 
 Internally, Django views an entire collection of code, what most would call a "website," as a
 <a href="https://docs.djangoproject.com/en/5.1/intro/tutorial01/#creating-a-project">
 project
 </a>
 . This is where the settings and configuration for a specific Django website are contained. Inside that project are 1 or more
 <a href="https://docs.djangoproject.com/en/5.1/intro/tutorial01/#creating-the-polls-app">
 apps
 </a>
 . An app is usually a specific sub-system used within the project. It's a collection of related code that provides specific functionality that's available to the rest of the project.
 
 <h3>
 A Github Example
 </h3>
 
 We can look at GitHub and how its functionality is split up as an example.
 
 Note
 
 : Github is NOT built with Django. But it's a web application that's known to the people who'll probably be reading this post. So, we'll pretend Github is built in Django for this example.
 
 
 Looking at the
 <a href="https://github.com/python/cpython">
 repository for Python
 </a>
 , we can see that
 <a href="https://github.com/python/cpython/issues">
 the issue tracker
 </a>
 ,
 <a href="https://github.com/python/cpython/pulls">
 management of pull requests
 </a>
 , and
 <a href="https://github.com/python/cpython/actions">
 tracking CI/CD activity
 </a>
 are all handling different tasks in different parts of the GitHub web application. But those bits of functionality are available to be reused across the web app on each different repository. When I talk about "bits of functionality" from a Django perspective, I'm talking about the database tables, views, other code and endpoints related to each task. So, the tables, views, other code and endpoints needed to manage Github Issues would all live in one app, perhaps called
 <code>
 issues
 </code>
 . It would be the same for the
 <code>
 pull_requests
 </code>
 and
 <code>
 ci_actions
 </code>
 apps. As such, that functionality is available to any other part of the larger Github project. At the same time, any changes that needed to be made to one of those apps (model updates, view changes, new endpoints, etc.) can be localized in that specific app.
 
 
 In Django, as with most web application frameworks, visiting a certain URL causes a specific section of code to be run. In this example, that would be the code in the
 <code>
 issues
 </code>
 ,
 <code>
 pull_requests
 </code>
 or
 <code>
 ci_actions
 </code>
 apps.
 
 
 One of the best things about apps is that they can be used between
 
 different
 
 projects. It's this
 <a href="https://docs.djangoproject.com/en/5.1/intro/reusable-apps/#reusability-matters">
 reusability
 </a>
 that makes Django apps especially valuable. In many ways, a Django app can be seen as Django's analogy to Python packages. And they serve a very similar role: you don't have to re-invent something that already exists. While most 3rd party Django apps get downloaded from
 <a href="https://pypi.org">
 PyPI
 </a>
 like other Python packages, you can search for a Django app to fit your needs there or at
 <a href="https://djangopackages.org">
 Django Packages
 </a>
 .
 
 <h2>
 Building Your Own Django App
 </h2>
 <h3>
 Developer-Facing Benefits
 </h3>
 
 The benefits of using a third-party app are clear: you get new functionality added to your project. And you don't have to write/test/debug new code. You usually only have to make a few configuration changes.
 
 
 But when it comes to the code you're writing yourself, some developers may wonder why they should bother creating separate apps inside their projects. Won't that just add extra complexity? If not, then what are the benefits?
 
 <h3>
 Code Modularity
 </h3>
 
 By having code that performs a specific set of functions separated into an app, it's not mixed in with your larger project monolith. As a result, you end up with code that's easier to test, document, and update. Instead of having to dig through your entire code base, you can focus on JUST the parts you need to look at. You may also improve the effectiveness of your testing by realizing that some subsystems (apps) need more or less testing than others. You can tune your coverage strategy on a per-app basis. This modularity can also provide clearer internal imports due to app namespacing.
 
 <h3>
 Reusability
 </h3>
 
 You may find yourself writing code that is nearly identical across multiple projects. Instead of copying/pasting that code several times and hoping you've made the right changes, you can install your app into that project. This way, any changes that need to be made to that app can be made in one place instead of several. This might not be one you've considered, given that we don't always know what the full design will be as we're working on something, and it can take time to tell if a certain chunk of code will be useful in other projects.
 
 
 On the topic of reusability, this doesn't mean you have to share this app with the world. You can put it on Github and
 <code>
 pip install
 </code>
 it
 <a href="https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/">
 from a Git repository
 </a>
 . That way, it's easily available to all your other projects and other developers on your team.
 
 <h3>
 A Microservices Analogy
 </h3>
 
 Here's another way of looking at the relationship between a Django project and an app. We can make a comparison to the monolithic and microservice approaches to software architecture. An app in Django can be compared to a microservice but with MUCH less overhead. But an app and a microservice fill similar roles. They help deal with complexity by decomposing your solution into smaller, more manageable pieces. So, if you're working on a Django project and thinking you need a microservice, that's probably a sign that you should convert part of your monolith into an app. And, if at some point you realize you truly DO need a microservice, it's much easier to convert an app into a microservice. You already have the encapsulated structure in place. In short, breaking the codebase of a monolithic Django project into apps
 
 (where appropriate, not just for the sake of doing it)
 
 can provide many of the benefits of distributed systems without most of the problems.
 
 
 There may be a question about how much "overhead" there is in turning your working code into a reusable app? The answer is, "not much". I won't go into detail here, but the Django docs have you covered from
 <a href="https://docs.djangoproject.com/en/5.1/intro/tutorial01/">
 start
 </a>
 to
 <a href="https://docs.djangoproject.com/en/5.1/intro/reusable-apps/">
 finish
 </a>
 .
 
 <h2>
 End-User Facing Benefits
 </h2>
 
 The assumption here is you are building a Django project for other people to use, not just a personal project. Perhaps it's a client you're doing freelance or agency work for. Or, you may be a developer inside a larger organization, building web apps for your co-workers to use. In situations like these, there may be concerns about "adding complexity" or "slowing down development" by creating separate apps within a larger project. As noted above, that's not really a problem, but here are a few things to keep in mind if a concern like that is raised.
 
 
 There are two main benefits users of your Django project will see from creating separate apps within the project. First, all users will benefit from better naming conventions and clarity about which part of the web app they're using. Most won't care about the implementation details, but knowing that they can go directly to
 <code>
 https://CompanyName/task_1/
 </code>
 or
 <code>
 https://CompanyName/task_2/
 </code>
 to do what they need to will simplifiy things for them. Contrast this with needing to go to
 <code>
 https://CompanyName/all_the_tasks/
 </code>
 and then search for what they need.
 
 
 Second, there may be a group of staff or superusers who will have access to the Django Admin. These may be people such as managers, department heads, and the like. For those users, having your code separated into apps will create automatic separation in the Django admin. This will make it easier for those folks to find and focus on the specific app they need, instead of sorting through the entire project.
 
 <h2>
 Next: Django App Of The
 <code>
 {{ variable_time_period }}
 </code>
 </h2>
 
 Now that we've set a bit of foundation, we'll be looking at various Django apps and how they can be used. Some will be apps we're currently using on projects. Some will be apps we think are interesting. We probably won't be doing an app every week, but we'll try to keep the cadence regular enough to be compelling! Stay tuned!
 
 </div>
</div>

Introduction
  
  
   We'll be doing a semi-regular series of blog posts about various useful Django apps. However, it seemed like a good idea to lay some groundwork first. That will help us do a few things:
  
  
   
    define
    
     app
    
    along with a few other similar terms, and get some namespace confusion out of the way
   
   
    understand the value, as a
    
     developer
    
    , of creating separate apps in your Django projects
   
   
    understand the value, as a
    
     developer
    
    or
    
     end-user
    
    of a Django project, of using separate apps (third-party or internally-created) in your Django projects
   
  
  
   What is an App? Context matters.
  
  
   If you go to the Django home page, https://www.djangoproject.com, the blurb at the top says:
   
    Django makes it easier to build better web apps more quickly and with less code.
   
   Django is often described as a
   
    web application framework
   
   or something that you use to create web applications (web apps). I've used this description myself. I have also purposefully distinguished between a
   
    web app
   
   and a
   
    website
   
   during a Django tutorial I taught. I've also written a
   
    blog post
   
   on that topic.  So, if Django is used to BUILD web apps, why are we talking about apps IN Django? The context shifts a bit if you're looking at something built with Django from the outside vs. from the inside.
  
  
   A View From The Inside
  
  
   From the outside, the specific nomenclature is much less important. But from the inside, as someone building something with Django, the specific terminology has more meaning. But, it can still be a little confusing.
  
  
   Internally, Django views an entire collection of code, what most would call a "website," as a
   
    project
   
   . This is where the settings and configuration for a specific Django website are contained. Inside that project are 1 or more
   
    apps
   
   .  An app is usually a specific sub-system used within the project. It's a collection of related code that provides specific functionality that's available to the rest of the project.
  
  
   A Github Example
  
  
   We can look at GitHub and how its functionality is split up as an example.
   
    Note
   
   : Github is NOT built with Django. But it's a web application that's known to the people who'll probably be reading this post. So, we'll pretend Github is built in Django for this example.
  
  
   Looking at the
   
    repository for Python
   
   , we can see that
   
    the issue tracker
   
   ,
   
    management of pull requests
   
   , and
   
    tracking CI/CD activity
   
   are all handling different tasks in different parts of the GitHub web application. But those bits of functionality are available to be reused across the web app on each different repository. When I talk about "bits of functionality" from a Django perspective, I'm talking about the database tables, views, other code and endpoints related to each task. So, the tables, views, other code and endpoints needed to manage Github Issues would all live in one app, perhaps called
   
    issues
   
   . It would be the same for the
   
    pull_requests
   
   and
   
    ci_actions
   
   apps. As such, that functionality is available to any other part of the larger Github project. At the same time, any changes that needed to be made to one of those apps (model updates, view changes, new endpoints, etc.) can be localized in that specific app.
  
  
   In Django, as with most web application frameworks, visiting a certain URL causes a specific section of code to be run. In this example, that would be the code in the
   
    issues
   
   ,
   
    pull_requests
   
   or
   
    ci_actions
   
   apps.
  
  
   One of the best things about apps is that they can be used between
   
    different
   
   projects. It's this
   
    reusability
   
   that makes Django apps especially valuable. In many ways, a Django app can be seen as Django's analogy to Python packages. And they serve a very similar role: you don't have to re-invent something that already exists. While most 3rd party Django apps get downloaded from
   
    PyPI
   
   like other Python packages, you can search for a Django app to fit your needs there or at
   
    Django Packages
   
   .
  
  
   Building Your Own Django App
  
  
   Developer-Facing Benefits
  
  
   The benefits of using a third-party app are clear: you get new functionality added to your project. And you don't have to write/test/debug new code. You usually only have to make a few configuration changes.
  
  
   But when it comes to the code you're writing yourself, some developers may wonder why they should bother creating separate apps inside their projects. Won't that just add extra complexity? If not, then what are the benefits?
  
  
   Code Modularity
  
  
   By having code that performs a specific set of functions separated into an app, it's not mixed in with your larger project monolith. As a result, you end up with code that's easier to test, document, and update. Instead of having to dig through your entire code base, you can focus on JUST the parts you need to look at. You may also improve the effectiveness of your testing by realizing that some subsystems (apps) need more or less testing than others. You can tune your coverage strategy on a per-app basis. This modularity can also provide clearer internal imports due to app namespacing.
  
  
   Reusability
  
  
   You may find yourself writing code that is nearly identical across multiple projects. Instead of copying/pasting that code several times and hoping you've made the right changes, you can install your app into that project. This way, any changes that need to be made to that app can be made in one place instead of several. This might not be one you've considered, given that we don't always know what the full design will be as we're working on something, and it can take time to tell if a certain chunk of code will be useful in other projects.
  
  
   On the topic of reusability, this doesn't mean you have to share this app with the world. You can put it on Github and
   
    pip install
   
   it
   
    from a Git repository
   
   . That way, it's easily available to all your other projects and other developers on your team.
  
  
   A Microservices Analogy
  
  
   Here's another way of looking at the relationship between a Django project and an app. We can make a comparison to the monolithic and microservice approaches to software architecture. An app in Django can be compared to a microservice but with MUCH less overhead. But an app and a microservice fill similar roles. They help deal with complexity by decomposing your solution into smaller, more manageable pieces. So, if you're working on a Django project and thinking you need a microservice, that's probably a sign that you should convert part of your monolith into an app. And, if at some point you realize you truly DO need a microservice, it's much easier to convert an app into a microservice. You already have the encapsulated structure in place. In short, breaking the codebase of a monolithic Django project into apps
   
    (where appropriate, not just for the sake of doing it)
   
   can provide many of the benefits of distributed systems without most of the problems.
  
  
   There may be a question about how much "overhead" there is in turning your working code into a reusable app? The answer is, "not much". I won't go into detail here, but the Django docs  have you covered from
   
    start
   
   to
   
    finish
   
   .
  
  
   End-User Facing Benefits
  
  
   The assumption here is you are building a Django project for other people to use, not just a personal project. Perhaps it's a client you're doing freelance or agency work for. Or, you may be a developer inside a larger organization, building web apps for your co-workers to use. In situations like these, there may be concerns about "adding complexity" or "slowing down development" by creating separate apps within a larger project. As noted above, that's not really a problem, but here are a few things to keep in mind if a concern like that is raised.
  
  
   There are two main benefits users of your Django project will see from creating separate apps within the project. First, all users will benefit from better naming conventions and clarity about which part of the web app they're using. Most won't care about the implementation details, but knowing that they can go directly to
   
    https://CompanyName/task_1/
   
   or
   
    https://CompanyName/task_2/
   
   to do what they need to will simplifiy things for them. Contrast this with needing to go to
   
    https://CompanyName/all_the_tasks/
   
   and then search for what they need.
  
  
   Second, there may be a group of staff or superusers who will have access to the Django Admin. These may be people such as managers, department heads, and the like. For those users, having your code separated into apps will create automatic separation in the Django admin. This will make it easier for those folks to find and focus on the specific app they need, instead of sorting through the entire project.
  
  
   Next: Django App Of The
   
    {{ variable_time_period }}
   
  
  
   Now that we've set a bit of foundation, we'll be looking at various Django apps and how they can be used. Some will be apps we're currently using on projects. Some will be apps we think are interesting. We probably won't be doing an app every week, but we'll try to keep the cadence regular enough to be compelling! Stay tuned!

What IS a Django App?

Step-by-step guide to integrating Meilisearch with Django, complete with automatic indexing, typo tolerance, and relevant filtering capabilities.

# compose.yml 
services:
 search:
 image: getmeili/meilisearch:v1.7
 volumes:
 - ./meili-data:/meili_data
 ports:
 - "7700:7700"

docker-compose up -d search

pip install meilisearch

# settings.py
SEARCH_API_URL = env("SEARCH_API_URL", default="http://search:7700/")
SEARCH_API_KEY = env("SEARCH_API_KEY", default=None)
SEARCH_INDEXES = {
 "main": "main_search",
 # You can define additional indexes here for different purposes
 # "autocomplete": "autocomplete_search",
 # "admin": "admin_search",
}
# Control whether we index the search or not
INDEX_SEARCH = env.bool("INDEX_SEARCH", default=True)

# products/models.py
from django.db import models

class Product(models.Model):
 name = models.CharField(max_length=255)
 description = models.TextField(blank=True)
 price = models.DecimalField(max_digits=10, decimal_places=2)
 sku = models.CharField(max_length=50, unique=True)
 brand = models.CharField(max_length=100, blank=True)
 active = models.BooleanField(default=True)
 created_at = models.DateTimeField(auto_now_add=True)
 updated_at = models.DateTimeField(auto_now=True)

 def get_absolute_url(self):
 return f"/products/{self.id}/"

 def __str__(self):
 return self.name

class Product(models.Model):
 name = models.CharField(max_length=255)
 sku = models.CharField(max_length=50, unique=True)
 description = models.TextField()
 price = models.DecimalField(max_digits=10, decimal_places=2)

class Category(models.Model):
 name = models.CharField(max_length=255)
 slug = models.SlugField(max_length=100)
 description = models.TextField()
 active = models.BooleanField(default=True)

# search/schemas.py
from pydantic import BaseModel

class SearchSchema(BaseModel):
 """
 Pydantic model for our main search schema
 """
 id: str
 title: str | None = None
 type: str # 'product', 'category', etc.
 url: str
 active: bool = True

 # Product fields
 product_name: str | None = None
 product_description: str | None = None
 brand_name: str | None = None
 sku: str | None = None

# products/models.py
from django.db import models
from search.schemas import SearchSchema

class Product(models.Model):
 # fields and methods as before

 def search_data(self):
 """Return data for the search index"""
 return SearchSchema(
 # prefix the ID with the "type" for the SearchSchema
 id=f"product-{self.id}",
 title=self.name,
 type="product",
 url=self.get_absolute_url(),
 active=self.active,
 product_name=self.name,
 product_description=self.description,
 brand_name=self.brand,
 sku=self.sku,
 )

def get_meilisearch_client():
 """Return a meilisearch client"""
 url = settings.SEARCH_API_URL
 api_key = settings.SEARCH_API_KEY
 client = meilisearch.Client(url, api_key)
 return client

def update_object(obj):
 """Update a single object in the search index or delete if inactive"""
 client = get_meilisearch_client()
 index_name = settings.SEARCH_INDEXES["main"]
 index = client.index(index_name)

 if obj["active"]:
 # Update the object in the index
 index.add_documents([obj])
 else:
 # Delete the object from the index
 index.delete_document(obj["id"])

def build_main_indexes(verbose=False):
 """Build the main search index with all searchable models"""
 from products.models import Product # Import your models

 client = get_meilisearch_client()
 index_name = settings.SEARCH_INDEXES["main"]
 index = client.index(index_name)

 # Configure the index settings
 index_settings = {
 "filterableAttributes": ["type", "active"],
 "searchableAttributes": [
 "title",
 "product_name",
 "product_description",
 "sku",
 "brand_name",
 ],
 }
 index.update_settings(index_settings)

 # Index all active products
 products = Product.objects.filter(active=True)
 if verbose:
 print(f"Indexing {products.count()} products...")

 product_docs = [product.search_data().dict() for product in products]
 if product_docs:
 index.add_documents(product_docs)

def rebuild_main_indexes(verbose=False):
 """Completely rebuild the main search index"""
 client = get_meilisearch_client()
 index_name = settings.SEARCH_INDEXES["main"]

 # Delete the index if it exists
 try:
 client.delete_index(index_name)
 except meilisearch.errors.MeiliSearchApiError:
 pass

 # Create the index and build it
 client.create_index(index_name)
 build_main_indexes(verbose=verbose)

# search/mixins.py
from django.conf import settings
from search.utils import update_object

class UpdateSearchMixin:
 """
 Mixin to update the search index when a model is saved
 """
 def update_search(self):
 if settings.INDEX_SEARCH:
 update_object(self.search_data().dict())

 def save(self, *args, **kwargs):
 """ Override the save method so we can call update_search after save """
 # Call the original save method
 super().save(*args, **kwargs)
 # Update the search index
 self.update_search()

# products/models.py
from django.db import models
from search.schemas import SearchSchema
from search.mixins import UpdateSearchMixin

# Add UpdateSearchMixin
class Product(UpdateSearchMixin, models.Model):
 ...

# search/management/commands/index_search.py
from __future__ import annotations

import djclick as click

from search.utils import rebuild_main_indexes


@click.command()
@click.option("--verbose", is_flag=True, default=False)
def main(verbose):
 """Index objects in Meilisearch."""
 click.secho("Rebuilding main indexes...", fg="green", nl=False)
 rebuild_main_indexes(verbose=verbose)
 click.echo("Indexes built.")

# search/management/commands/index_search.py
from __future__ import annotations

import time
import djclick as click
from django.conf import settings
from products.models import Product, Category
from search.utils import get_meilisearch_client

@click.command()
@click.option("--verbose", is_flag=True, default=False)
@click.option("--batch-size", default=1000, help="Batch size for indexing")
def main(verbose, batch_size):
 """Rebuild search indexes in Meilisearch with batch processing."""
 start_time = time.time()
 click.secho("Rebuilding search indexes...", fg="green")

 # Get client and recreate index
 client = get_meilisearch_client()
 index_name = settings.SEARCH_INDEXES["main"]

 # Delete and recreate index
 try:
 client.delete_index(index_name)
 except Exception:
 pass

 client.create_index(index_name)
 index = client.index(index_name)

 # Configure index settings
 click.echo("Configuring index settings...")
 index_settings = {
 "filterableAttributes": ["type", "active"],
 "searchableAttributes": [
 "title", "product_name", "product_description", 
 "sku", "brand_name", "category_name"
 ],
 }
 index.update_settings(index_settings)

 # Index products in batches
 products = Product.objects.filter(active=True)
 total_products = products.count()

 if verbose:
 click.echo(f"Indexing {total_products} products in batches of {batch_size}...")

 # Process in batches to avoid memory issues with large datasets
 batch_count = 0
 for i in range(0, total_products, batch_size):
 batch = products[i:i+batch_size]
 product_docs = [p.search_data().dict() for p in batch]
 if product_docs:
 index.add_documents(product_docs)

 batch_count += 1
 if verbose:
 click.echo(f"Processed batch {batch_count}, {min(i+batch_size, total_products)}/{total_products} products")

 # Index categories (typically smaller, so we do it all at once)
 categories = Category.objects.filter(active=True)
 category_docs = [cat.search_data().dict() for cat in categories]
 if category_docs:
 index.add_documents(category_docs)

 elapsed_time = time.time() - start_time
 click.secho(f"✓ Indexing completed in {elapsed_time:.2f} seconds", fg="green")

# products/models.py
class Category(UpdateSearchMixin, models.Model):
 name = models.CharField(max_length=255)
 description = models.TextField(blank=True)
 active = models.BooleanField(default=True)

 def get_absolute_url(self):
 return f"/categories/{self.id}/"

 def search_data(self):
 return SearchSchema(
 id=f"category-{self.id}",
 title=self.name,
 type="category",
 url=self.get_absolute_url(),
 active=self.active,
 category_name=self.name,
 category_description=self.description,
 products_count=self.products.count(),
 )

# search/schemas.py
class SearchSchema(BaseModel):
 """
 Pydantic model for our main search schema
 """
 # other fields as before... 

 # Category fields
 category_name: str | None = None
 category_description: str | None = None
 products_count: int | None = None

def build_main_indexes(verbose=False):
 """Build the main search index with all searchable models"""
 from products.models import Product, Category # Import your models

 client = get_meilisearch_client()
 index_name = settings.SEARCH_INDEXES["main"]
 index = client.index(index_name)

 # Configure the index settings
 index_settings = {
 "filterableAttributes": ["type", "active"],
 "searchableAttributes": [
 ...
 "category_name",
 "category_description",
 ],
 }
 index.update_settings(index_settings)

 # Index all active products as before... 

 # Index all active categories
 categories = Category.objects.filter(active=True)
 if verbose:
 print(f"Indexing {categories.count()} categories...")

 category_docs = [cat.search_data().dict() for cat in categories]
 if category_docs:
 index.add_documents(category_docs)

# search/views.py
from django.shortcuts import render
from django.conf import settings
from search.utils import get_meilisearch_client

def search(request):
 """Search view"""
 query = request.GET.get("q", "").strip()
 type_filter = request.GET.get("type", None)
 results = []

 if query:
 client = get_meilisearch_client()
 index = client.index(settings.SEARCH_INDEXES["main"])

 # Build filter string using your filterable attributes 
 filter_str = "active = true"
 if type_filter:
 filter_str += f" AND type = {type_filter}"

 # Perform search
 search_results = index.search(
 query, 
 {
 "filter": filter_str,
 "limit": 50
 }
 )
 results = search_results["hits"]

 return render(
 request,
 "search/results.html",
 {
 "results": results,
 "query": query,
 "type_filter": type_filter
 },
 )


{% extends "base.html" %}

{% block content %}
<div class="search-container">
 
 <form method="get" action="{% url 'search' %}">
 <input type="text" name="q" value="{{ query }}" placeholder="Search...">
 <button type="submit">Search</button>
 </form>

 
 {% if query %}
 <h2>Results for "{{ query }}"</h2>
 {% if results %}
 <div class="search-results">
 {% for result in results %}
 <div class="search-result">
 <h3><a href="{{ result.url }}">{{ result.title }}</a></h3>
 </div>
 {% endfor %}
 </div>
 {% else %}
 No results found.
 {% endif %}
 {% endif %}
</div>
{% endblock %}

# urls.py
from django.urls import path
from search.views import search

urlpatterns = [
 # ... other URLs
 path('search/', search, name='search'),
]

 
 
 For a production application, you might want to enhance this with:
 
 
 
 
 Pagination
 
 : For handling large result sets
 
 
 
 Highlighting
 
 : To show users where their search terms matched
 
 
 
 Faceted search
 
 : To allow filtering by multiple attributes
 
 
 
 Autocomplete
 
 : To suggest search terms as users type
 
 
 
 Analytics
 
 : To track popular searches and improve your search experience
 
 
 
 Meilisearch supports all these features through its API, making it easy to build a sophisticated search experience as your application grows.
 
 
 See It In Action: Surplus Sales Case Study
 
 
 Want to see what a production Meilisearch implementation looks like? Visit our client
 
 Surplus Sales
 
 and try out their search functionality. Pay special attention to:
 
 
 
 
 Typo tolerance
 
 : Try searching for "trnasistors" (misspelled) and notice how it still finds what you need
 
 
 
 Speed
 
 : The millisecond response times, even when filtering through their 70,000+ item catalog
 
 
 
 Relevance
 
 : How the most relevant parts appear at the top of results
 
 
 
 Complex metadata handling
 
 : Search by part numbers, specifications, or descriptions
 
 
 
 Their implementation handles all the concepts we've covered in this tutorial. It's a great example of how these techniques scale to real-world applications.
 
 
 Alternative Approach: Using django-meili
 
 
 If you prefer a more Django-native approach with less custom code, you might want to check out
 
 django-meili
 
 . This package provides a more Haystack-like experience for integrating Meilisearch with Django. I haven't used it, but from what I can tell, these are the main differences between using django-meili and implementing something more like our custom Meilisearch implementation:
 
 
 
 
 Model-focused
 
 : django-meili is designed around indexing individual Django models, which works well if you're searching just one model at a time
 
 
 
 Less flexible
 
 : Our unified schema approach gives you more control over how different models are represented in search results
 
 
 
 Easier setup
 
 : django-meili requires less boilerplate code to get started
 
 
 
 Django-native
 
 : It follows Django conventions more closely with a familiar API
 
 
 
 django-meili might be a good choice if:
 
 
 
 You're primarily searching within a single model type
 
 
 You prefer a more Django-integrated approach with less custom code
 
 
 You don't need the flexibility of a unified schema across different model types
 
 
 
 Further Reading
 
 
 
 
 Meilisearch Official Documentation
 
 
 
 
 Meilisearch Python Client
 
 
 
 
 Meilisearch Settings Reference
 
 
 
 
 Meilisearch Search Parameters
 
 
 
 
 django-meili GitHub Repository
 
 
 
 
 Need help implementing advanced search for your Django project?
 
 Contact our team at Revsys
 
 for expert
 
 Django consulting
 
 . We've implemented search solutions for clients ranging from small startups to large enterprises, and we'd be happy to help you build a search experience that delights your users.

How to Add Blazing Fast Search to Your Django Site with Meilisearch

Test output is often an afterthought. You can improve your flow and slightly gamify your bug hunting by combining the wonderful Rich Python library and pytest.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h2>
 Debugging complex code is not usually fun
 </h2>
 
 It's hard to get motivated when faced with a big pile of numbers that just aren't lining up in the ways they are supposed to. Stupid numbers, do what you're told!
 
 <h2>
 The task at hand
 </h2>
 
 I've been rebuilding a 15 to 20-year-old ColdFusion currency trading learning simulation for a client. The math involved is mostly contained in SQL Server stored procedures, some values in tables are really constants (or at least most of the time), and variable names between steps of the process aren't consistent. This has made the rebuilding effort harder than it originally appeared. Add in finding some undesired behaviors in the old app and the desire to improve these situations going forward has been a bit of a slog actually.
 
 
 I knew that today was the day I had to just dig in and iterate on this code until all of the numbers were correct now that I had a known good set of values to work against.
 
 
 Since I needed to compare several numbers together, I thought I might use a
 <a href="https://rich.readthedocs.io/en/stable/tables.html">
 Rich Table
 </a>
 to make the output a little better organized. And I'm VERY glad I did.
 
 
 Here is what I started with:
 
 </div>
</div>
<div class="w-block-content block-content">
 
 
 <img alt="Initial boring pytest output" class="richtext-image full-width" height="742" src="https://sfo2.digitaloceanspaces.com/revsys-com-prod-media/images/CleanShot_2024-02-03_at_08.18.27.width-800.png" width="800"/>
 
 
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 Not exactly pretty. It spit out the numbers it was calculating and I could compare them against the known good values visually. Looking and re-re-reading the numbers a half dozen times I was already bored and feeling tired despite having too much caffeine in my system.
 
 
 So I implemented all of the expected, calculated and differences between the two in a Rich Table. I took a couple of moments to adjust some colors and right justifying all of these numbers because I knew I was going to be staring at this
 
 all freaking day
 
 .
 
 </div>
</div>
<div class="w-block-content block-content">
 
 
 <img alt="Initial Python Rich table formatting" class="richtext-image full-width" height="475" src="https://sfo2.digitaloceanspaces.com/revsys-com-prod-media/images/CleanShot_2024-02-03_at_09.15.54.width-800.png" width="800"/>
 
 
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h2>
 The debugging
 </h2>
 
 I then went about debugging the first
 
 Total Unhedged
 
 number because all of the following calculations depended on this number being correct. And I quickly found the bug!
 
 
 I would love to say it was because of this great new visualization, but it was just closely re-reading my Python code and comparing it (
 
 yet again
 
 ) to the original portion of a stored procedure to find my subtle mistake.
 
 
 One down, 6 more to go I thought. This is going to be a long day, but it turned out two more of the values were
 
 NEARLY
 
 correct now, just off due to rounding. This
 
 WAS
 
 easier to spot because of the tabular layout. I treated myself to a bit more table improvement, I wrote a little function named
 <code>
 calc_diff()
 </code>
 that took the expected and actual values and color coded the difference red if there was a difference and green if not.
 
 </div>
</div>
<div class="w-block-content block-content">
 
 
 <img alt="Improved table with red/green color coding" class="richtext-image full-width" height="341" src="https://sfo2.digitaloceanspaces.com/revsys-com-prod-media/images/CleanShot_2024-02-03_at_09.36.37.width-800.png" width="800"/>
 
 
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h2>
 Table code example
 </h2>
 
 The code for this is surprisingly easy.
 <a href="https://github.com/Textualize/rich">
 Rich
 </a>
 was already a dependency of something else in my project's virtualenv so I didn't even need to install it. Here is a simplified example of the code for you:
 
 </div>
</div>
<div class="w-block-code block-code">
 <div class="codehilite">
 <pre>from decimal import Decimal

from rich.console import Console
from rich.table import Table
from rich.text import Text 

def calc_diff(expected, actual):
 diff = expected - actual

 color = "red"
 if diff == 0:
 color = "green"

 text = Text(str(diff))
 text.stylize(color)

 return text

# My actual pytest test
def test_ex3_math(ex3_params):
 expected_total_unhedged = Decimal("3.394148")

 # call a method on a fixture class that does the math calculation for us, yours
 # would obviously be different 
 total_unhedged = ex3_params.total_unhedged()

 # Build our table
 table = Table(
 title="Exercise 3 Answers", title_style="gold1", style="deep_sky_blue3"
 )
 table.add_column(
 "Name", style="turquoise2", header_style="turquoise2", no_wrap=True
 )
 table.add_column("Expected", header_style="turquoise2", justify="right")
 table.add_column("Actual", header_style="turquoise2", justify="right")
 table.add_column("Difference", header_style="turquoise2", justify="right")

 # Total Unhedged - just showing you one row here for sake of brevity
 table.add_row(
 "Total Unhedged",
 str(expected_total_unhedged),
 str(total_unhedged),
 calc_diff(expected_total_unhedged, total_unhedged),
 )

 # Output the table 
 console = Console(color_system="256")
 console.print(table)

 # Trigger our test to fail artificially 
 assert False
</pre>
 </div>
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h2>
 Conclusion
 </h2>
 
 Was it worth the extra time?
 
 DEFINITELY!
 
 I not only made it easier to compare the values as I worked but also motivated me a little more than usual as I turned each red line green.
 
 
 Every little bit helps, right? Hopefully, you enjoyed this protip and can put it use in one of your upcoming debugging sessions.
 
 
 If you or your company struggles with testing your Python or Django apps, check out
 <a href="/teststart/">
 TestStart
 </a>
 our testing consulting package to help jump start your team into better productivity.
 
 </div>
</div>

from decimal import Decimal

from rich.console import Console
from rich.table import Table
from rich.text import Text 

def calc_diff(expected, actual):
        diff = expected - actual

        color = "red"
        if diff == 0:
            color = "green"

        text = Text(str(diff))
        text.stylize(color)

        return text

# My actual pytest test
def test_ex3_math(ex3_params):
    expected_total_unhedged = Decimal("3.394148")

    # call a method on a fixture class that does the math calculation for us, yours
   # would obviously be different 
    total_unhedged = ex3_params.total_unhedged()

    # Build our table
    table = Table(
        title="Exercise 3 Answers", title_style="gold1", style="deep_sky_blue3"
    )
    table.add_column(
        "Name", style="turquoise2", header_style="turquoise2", no_wrap=True
    )
    table.add_column("Expected", header_style="turquoise2", justify="right")
    table.add_column("Actual", header_style="turquoise2", justify="right")
    table.add_column("Difference", header_style="turquoise2", justify="right")

    # Total Unhedged - just showing you one row here for sake of brevity
    table.add_row(
        "Total Unhedged",
        str(expected_total_unhedged),
        str(total_unhedged),
        calc_diff(expected_total_unhedged, total_unhedged),
    )

   # Output the table 
   console = Console(color_system="256")
   console.print(table)

   # Trigger our test to fail artificially 
   assert False

 


 
  
   Conclusion
  
  
   Was it worth the extra time?
   
    DEFINITELY!
   
   I not only made it easier to compare the values as I worked but also motivated me a little more than usual as I turned each red line green.
  
  
   Every little bit helps, right? Hopefully, you enjoyed this protip and can put it use in one of your upcoming debugging sessions.
  
  
   If you or your company struggles with testing your Python or Django apps, check out
   
    TestStart
   
   our testing consulting package to help jump start your team into better productivity.

"En-Rich" your Python testing

A simple import trick to make it easy to keep your django-ninja view functions in different Django apps and files.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 I've been evaluating
 <a href="https://django-ninja.rest-framework.com/">
 django-ninja
 </a>
 recently, using it in a personal project to see when it might be appropriate for
our clients.
 
 <h2>
 The Problem - How to have multiple view files
 </h2>
 
 One thing that was not clear was how to break up your API views and sprinkle
them around in multiple files. The default tutorial and documentation is not
bad, but just does not cover this small thing.
 
 
 The way django-ninja works is that you decorate functional views with
 <code>
 @api
 </code>
 where you indicate what HTTP method it is for and some other parameters.
Everything is perfect until you realize your views.py has grown huge or you
want to include api views from several Django applications.
 
 
 For those of us who are very familiar with DRF, it is not immediately clear how
you can break your views into multiple files.
 
 
 Let's use an example of having a Django apps named
 <code>
 core
 </code>
 ,
 <code>
 users
 </code>
 , and
 <code>
 posts
 </code>
 to mimic some sort of blog like software and our project directory, which contains
our settings and urls files will be named
 <code>
 config/
 </code>
 which is the standard way
we roll at REVSYS.
 
 
 Your first guess might be that you should create another instance of
 <code>
 NinjaAPI
 </code>
 and use that to decorate your views in each file. Unfortunately, because of how
the internal registry works for these, that would create multiple django-ninja
"sites", each with their own docs, etc. which is obviously not what we want.
 
 <h2>
 The Solution
 </h2>
 
 The easiest way to do this is to pass around your API decorator and ensure
your view files are imported before you call on Ninja to generate your URLs.
 
 
 While I hate having an app named
 <code>
 core
 </code>
 , I used it in this case. So we
create our API instance with the following:
 
 <div class="codehilite">
 <pre><code># File: core/api.py
from ninja import NinjaAPI

api = NinjaAPI(csrf=True)
</code></pre>
 </div>
 
 And then in our views we import this and use it:
 
 <div class="codehilite">
 <pre><code># File: users/views.py
from core.api import api

@api.get("users/something/"):
def get_user(request):
 # ... do something interesting here ...

# File: posts/views.py
from core.api import api

@api.get("posts/{username}/"):
def get_posts(requests, username: str):
 # ... do something interesting here ...
</code></pre>
 </div>
 
 Then the final bit is to make sure we import these files in our
 <code>
 urls.py
 </code>
 before
we call
 <code>
 api.urls
 </code>
 like this:
 
 <div class="codehilite">
 <pre><code># File: config/urls.py
import users.views
import posts.views
from core.api import api

urlpatterns = [
 path("api/", api.urls),
]
</code></pre>
 </div>
 <h2>
 Alternative Solution
 </h2>
 
 Turns out there is also a DRF like concept of
 <a href="https://django-ninja.rest-framework.com/guides/routers/">
 routers
 </a>
 which is honestly probably a better more
maintainable solution than the above.
 
 
 Thanks to
 <a href="https://twitter.com/uninen/status/1622007355067056132?s=46&amp;t=6Jl-2SgFBle7KLjsma1uQw">
 Ville S&auml;&auml;vuori
 </a>
 for point this out after I posted this.
 
 
 Hopefully, this saves you a bit of time when you first start using django-ninja!
 
 
 If you need help creating Django REST APIs don't hesitate to
 <a href="/contact/">
 reach out to us
 </a>
 !
 
 </div>
</div>

# File: core/api.py
from ninja import NinjaAPI

api = NinjaAPI(csrf=True)

# File: users/views.py
from core.api import api

@api.get("users/something/"):
def get_user(request):
   # ... do something interesting here ...

# File: posts/views.py
from core.api import api

@api.get("posts/{username}/"):
def get_posts(requests, username: str):
   # ... do something interesting here ...

# File: config/urls.py
import users.views
import posts.views
from core.api import api

urlpatterns = [
    path("api/", api.urls),
]

  
  
   Alternative Solution
  
  
   Turns out there is also a DRF like concept of
   
    routers
   
   which is honestly probably a better more
maintainable solution than the above.
  
  
   Thanks to
   
    Ville Säävuori
   
   for point this out after I posted this.
  
  
   Hopefully, this saves you a bit of time when you first start using django-ninja!
  
  
   If you need help creating Django REST APIs don't hesitate to
   
    reach out to us
   
   !

Breaking up django-ninja views

Sometimes you want your FloatFields to be nullable, but your JS code isn&#x27;t quite smart enough to handle it.

<div class="w-block-content block-content">
 
 I run into this situation every couple of years, and I always forget the solution. Even asked around the office and everyone had the same "Oh yeah, I remember doing that once... but now how".
 
 
 When these situations happen to us, it is often time to write a blog post!
 
 
 The situation I was faced with was I had:
 
 <ul>
 <li data-block-key="7lj4t">
 A model with a few nullable Django Model FloatFields
 </li>
 <li data-block-key="b2ksr">
 Django Rest Framework, using a ModelSerializer
 </li>
 <li data-block-key="rfo1">
 react-hook-form, react-query and standard fetch calls to POST the data to the endpoint
 </li>
 </ul>
 
 The issue is that we have a simple HTML text input to collect a possible float value. It's easy enough to mark this as not required on the form and any client-side form validation. However, it is NOT always that easy to handle what happens next. Because it's a text field, the JS tooling wants to send it as an empty string. So we end up with a payload that looks like:
 
</div>
<div class="w-block-code block-code">
 <div class="codehilite">
 <pre>{
 "name": "Frank Wiles",
 "weight": "",
}
</pre>
 </div>
</div>
<div class="w-block-content block-content">
 
 When what we'd really like to have is:
 
</div>
<div class="w-block-code block-code">
 <div class="codehilite">
 <pre>{
 "name": "Frank Wiles",
 "weight": null,
}
</pre>
 </div>
</div>
<div class="w-block-content block-content">
 
 DRF rejects this saying that an empty string is not a number. It is correct of course, just not being super helpful in this exact situation. So what is the solution? Enter BlankableFloatField
 
</div>
<div class="w-block-code block-code">
 <div class="codehilite">
 <pre>from rest_framework.serializers import FloatField


class BlankableFloatField(FloatField):
 """
 This accepts an empty string as None
 """

 def to_internal_value(self, data):
 if data == "":
 return None
 return super().to_internal_value(data)
</pre>
 </div>
</div>
<div class="w-block-content block-content">
 
 You can override this on your ModelSerializer by just specifying the fields manually like this:
 
</div>
<div class="w-block-code block-code">
 <div class="codehilite">
 <pre>class PersonSerializer(serializers.ModelSerializer):
 # ... your other fields here ... 
 weight = BlankableFloatField(required=False, allow_null=True, default=None)
</pre>
 </div>
</div>
<div class="w-block-content block-content">
 
 The solution isn't hard to execute, but it's hard to reason about and figure out the
 
 best
 
 place to adjust this in your Django project.
 
 
 Hopefully, the next time you find yourself with Javascript error in your console saying that an empty string is not a number this helps you out!
 
</div>

{
  "name": "Frank Wiles",
  "weight": "",
}

 
{
  "name": "Frank Wiles",
  "weight": null,
}

 
from rest_framework.serializers import FloatField


class BlankableFloatField(FloatField):
    """
    This accepts an empty string as None
    """

    def to_internal_value(self, data):
        if data == "":
            return None
        return super().to_internal_value(data)

 
class PersonSerializer(serializers.ModelSerializer):
    # ... your other fields here ... 
    weight = BlankableFloatField(required=False, allow_null=True, default=None)

 


 
  The solution isn't hard to execute, but it's hard to reason about and figure out the
  
   best
  
  place to adjust this in your Django project.
 
 
  Hopefully, the next time you find yourself with Javascript error in your console saying that an empty string is not a number this helps you out!

Sometimes you want your FloatFields to be nullable, but your JS code isn't quite smart enough to handle it.

Nullable DRF FloatFields and Javascript

I needed to structure permissions in an API view that had multiple user roles, and I learned about using the &amp; (and), | (or) and ~ (not) operators with Django REST Framework permissions.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 Recently, I needed to structure permissions in an API view so that someone could access an API if they were a superuser or they had some other status, like being a manager. The
 <a href="https://www.django-rest-framework.org/api-guide/permissions/#how-permissions-are-determined">
 Django Rest Framework Permissions docs
 </a>
 say that &ldquo;If any permission check fails an exceptions.PermissionDenied or exceptions.NotAuthenticated exception will be raised,&rdquo; which made me think I&rsquo;d have to override the
 <a href="http://www.cdrf.co/3.9/rest_framework.views/APIView.html">
 <code>
 get_permissions()
 </code>
 </a>
 method of the view or write a series of complicated
 <code>
 IsUserTypeA
 </code>
 ,
 <code>
 IsUserTypeAOrUserTypeB
 </code>
 permissions classes, in order to do what I wanted. That didn&rsquo;t seem ideal.
 
 
 Then a
 <a href="https://twitter.com/webology">
 colleague
 </a>
 pointed out one line in the DRF docs further down on the
 <a href="https://www.django-rest-framework.org/api-guide/permissions/#setting-the-permission-policy">
 same page
 </a>
 : &ldquo;Note: it supports &amp; (and), | (or) and ~ (not).&rdquo; This was exactly what I needed.
 
 
 Here&rsquo;s how it works.
 
 <h2>
 All permissions must return True
 </h2>
 
 The expected way that DRF permissions work is as stated above; when you list multiple permission classes in
 <code>
 permission_classes
 </code>
 , each of them must return True in order for the user to have access to that view. This is most likely what you&rsquo;re used to when implementing DRF permissions.
 
 <div class="codehilite">
 <pre><code>from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
 permission_classes = (IsAuthenticated, IsAdminUser)
</code></pre>
 </div>
 
 In this case, the user must be authenticated
 
 and
 
 be an admin user, or else they cannot access any part of the view.
 
 <h2>
 The | (or) operator
 </h2>
 
 Using the
 <code>
 |
 </code>
 (or) operator in DRF permissions allows you to set multiple conditions the user might meet and be able to access this view. For instance, for an educational app, a view might be available to students
 
 or
 
 faculty.
 
 <div class="codehilite">
 <pre><code>from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
 permission_classes = (IsAdminUser | IsStudent | IsFaculty)
</code></pre>
 </div>
 
 This expression
 <code>
 (IsAdminUser | IsStudent | IsFaculty)
 </code>
 allows a user who is an admin, a student, or a faculty member to access the view. Instead of needing to pass all three of these conditions, a user only needs to pass one.
 
 
 The way I accomplished this before was a custom permissions class named something like
 <code>
 IsAdminStudentOrFaculty
 </code>
 , but with multiple roles and complex permissions, this meant creating custom permission classes for nearly every combination of user role. (In this example, I refer to custom permissions
 <code>
 IsStudent
 </code>
 and
 <code>
 IsFaculty
 </code>
 ; there are
 <a href="https://www.django-rest-framework.org/api-guide/permissions/#examples">
 some examples in the docs
 </a>
 of how to implement custom permissions like these.)
 
 <h2>
 The &amp; (and) operator
 </h2>
 
 Especially combined with the
 <code>
 |
 </code>
 (or) operator, the
 <code>
 &amp;
 </code>
 (and) operator is really powerful. It enables you to set clear permissions boundaries without writing increasingly complex custom permissions classes.
 
 <div class="codehilite">
 <pre><code>from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
 permission_classes = (IsAuthenticated &amp; (IsAdminUser | IsFaculty | ReadOnly))
</code></pre>
 </div>
 
 This example,
 <code>
 (IsAuthenticated &amp; (IsAdminUser | IsFaculty | ReadOnly))
 </code>
 , requires that all users accessing this view be authenticated. In addition, it sets other permissions: a user must be authenticated
 
 and
 
 be an admin or a faculty member, or they only have &ldquo;read&rdquo; access to this view.
 
 <h2>
 The
 <code>
 ~
 </code>
 (not) operator
 </h2>
 
 The
 <code>
 ~
 </code>
 (not) operator allows you to simplify your permissions to permit everyone
 
 except
 
 users who meet specific criteria. Personally, I prefer to set permissions with positive language, like &ldquo;allow admins and faculty&rdquo; rather than &ldquo;don&rsquo;t allow students,&rdquo; but there are probably cases where the
 <code>
 ~
 </code>
 operator is a great option.
 
 <div class="codehilite">
 <pre><code>from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
 permission_classes = (~IsStudent &amp; IsAuthenticated)
</code></pre>
 </div>
 
 <code>
 (~IsStudent &amp; IsAuthenticated)
 </code>
 says that anyone who is authenticated and who is
 
 not
 
 a student can access this view.
 
 
 I hope you, like me, now can free yourself from the cumbersome task of writing too many custom permission classes in your apps with several different types of user roles and instead make use of simpler permission classes and the
 <code>
 &amp;
 </code>
 ,
 <code>
 |
 </code>
 and
 <code>
 ~
 </code>
 operators!
 
 <h2>
 Further Reading
 </h2>
 <ul>
 <li>
 <a href="https://www.django-rest-framework.org/api-guide/permissions">
 Django REST Framework Permissions
 </a>
 docs
 </li>
 <li>
 The
 <a href="https://github.com/encode/django-rest-framework/pull/5753">
 pull request
 </a>
 that added the
 <code>
 &amp;
 </code>
 (and) and
 <code>
 |
 </code>
 (or) operators. This, and the next pull request, are also the inspiration for some of my examples.
 </li>
 <li>
 The
 <a href="https://github.com/encode/django-rest-framework/pull/6361">
 pull request
 </a>
 that added the
 <code>
 ~
 </code>
 (not) operator
 </li>
 </ul>
 
 
 Thanks to
 <a href="https://twitter.com/webology">
 Jeff Triplett
 </a>
 for reviewing a draft of this article and finding this tip in the docs in the first place!
 
 
 </div>
</div>

from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
    permission_classes = (IsAuthenticated, IsAdminUser)

from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
    permission_classes = (IsAdminUser | IsStudent | IsFaculty)

from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
    permission_classes = (IsAuthenticated & (IsAdminUser | IsFaculty | ReadOnly))

from rest_framework.permissions import IsAuthenticated, IsAdminUser, ReadOnly
from rest_framework.viewsets import ModelViewSet

from my_app.permissions import IsStudent, IsFaculty


class MyModelViewSet(ModelViewSet):
    permission_classes = (~IsStudent & IsAuthenticated)

  
  
   
    (~IsStudent & IsAuthenticated)
   
   says that anyone who is authenticated and who is
   
    not
   
   a student can access this view.
  
  
   I hope you, like me, now can free yourself from the cumbersome task of writing too many custom permission classes in your apps with several different types of user roles and instead make use of simpler permission classes and the
   
    &
   
   ,
   
    |
   
   and
   
    ~
   
   operators!
  
  
   Further Reading
  
  
   
    
     Django REST Framework Permissions
    
    docs
   
   
    The
    
     pull request
    
    that added the
    
     &
    
    (and) and
    
     |
    
    (or) operators. This, and the next pull request, are also the inspiration for some of my examples.
   
   
    The
    
     pull request
    
    that added the
    
     ~
    
    (not) operator
   
  
  
   
    Thanks to
    
     Jeff Triplett
    
    for reviewing a draft of this article and finding this tip in the docs in the first place!

I needed to structure permissions in an API view that had multiple user roles, and I learned about using the & (and), | (or) and ~ (not) operators with Django REST Framework permissions.

A Tip About DRF Permissions

I was working on a project with a coworker recently and I noticed in one of their pull requests that they used a custom exception in one of our Django REST Framework viewsets. I prefer this way to what I was doing before, so I wanted to share it with you!

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 I was working on a project with a
 <a href="https://twitter.com/fwiles">
 coworker
 </a>
 recently and I noticed in one of their pull requests that they used a custom exception in one of our Django REST Framework viewsets. I prefer this way to what I was doing before, so I wanted to share it with you!
 
 <h2>
 My Less Clean, Less Consistent Exception Handling
 </h2>
 
 I made good use of the
 <a href="https://www.django-rest-framework.org/api-guide/status-codes/">
 status codes
 </a>
 page of the DRF docs. For example, if a user uploaded a CSV file that my view couldn&rsquo;t read, I might have had something like this:
 
 <div class="codehilite">
 <pre><code>from rest_framework import status
from rest_framework.response import Response
from rest_framework.views import APIView


class MyCSVUploadView(APIView):
 def post(self, request, *args, **kwargs):
 &hellip;
 if file_error:
 return Response(
 {"detail": "Unable to read file."}, 
 status=status.HTTP_400_BAD_REQUEST
 )
</code></pre>
 </div>
 
 This works just fine. But in some cases, I might return the same type of error response in multiple places. For a university that is no longer accepting applications, I might have multiple places where I am essentially passing the same &ldquo;Deadline passed&rdquo; message. Although the response is just one line of code, I have to find it, copy it, and paste it to make sure I&rsquo;m using the same wording, or deal with inconsistency in my exception messages.
 
 <h2>
 Custom Exception Classes for Clean Consistency
 </h2>
 
 For exception conditions that you encounter frequently in your code, you can override DRF&rsquo;s
 <code>
 APIException
 </code>
 class and create your own exceptions! Read more in
 <a href="https://www.django-rest-framework.org/api-guide/exceptions/#apiexception">
 the docs
 </a>
 .
 
 
 Import the
 <code>
 APIException
 </code>
 class and create a new class that inherits from it. Then set the
 <code>
 status_code
 </code>
 ,
 <code>
 default_detail
 </code>
 , and
 <code>
 default_code
 </code>
 attributes.
 
 <div class="codehilite">
 <pre><code># exceptions.py
from rest_framework.exceptions import APIException


class UnreadableCSVFile(APIException):
 status_code = 400
 default_detail = "Unable to read file."
 default_code = "unreadable_csv_file"
</code></pre>
 </div>
 
 The
 <code>
 status_code
 </code>
 attribute defines the HTTP status code you want to send in the response with this exception; refer to the
 <a href="https://www.django-rest-framework.org/api-guide/status-codes/">
 DRF list of status codes
 </a>
 for help. The
 <code>
 default_detail
 </code>
 attribute is the human-readable exception message you want to pass in the response. The
 <code>
 default_code
 </code>
 is a string that represents this specific exception.
 
 
 In your view, instead of manually returning a
 <code>
 Response()
 </code>
 object, raise your custom exception.
 
 <div class="codehilite">
 <pre><code># views.py
from rest_framework.views import APIView

From my_app.exceptions import UnreadableCSVFile

class MyCSVUploadView(APIView):
 def post(self, request, *args, **kwargs):
 &hellip;
 if file_error:
 raise UnreadableCSVFile()
</code></pre>
 </div>
 
 This allows my exceptions to be reusable across my app, which means the language I use in exception messages is always consistent.
 
 <h2>
 Custom Exception Handlers
 </h2>
 
 You can further customize your exceptions by creating a custom handler function (
 <a href="https://www.django-rest-framework.org/api-guide/exceptions/#custom-exception-handling">
 docs on custom exception handling
 </a>
 ). This is especially helpful if there are pieces of data, like the status code, that you want to ensure are included in all of your HTTP responses. This is a slightly different goal than what I refer to above, but it&rsquo;s worth knowing about. Here is the example from the docs:
 
 <div class="codehilite">
 <pre><code>from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):
 # Call REST framework's default exception handler first, 
 # to get the standard error response.
 response = exception_handler(exc, context)

 # Now add the HTTP status code to the response.
 if response is not None:
 response.data['status_code'] = response.status_code

 return response
</code></pre>
 </div>
 
 This adds the
 <code>
 status_code
 </code>
 to each exception response sent in your app.
 
 
 You would then add your custom exception handler to the
 <code>
 REST_FRAMEWORK
 </code>
 settings in your
 <code>
 settings.py
 </code>
 so this custom exception handler will be executed every time there is an API exception:
 
 <div class="codehilite">
 <pre><code>REST_FRAMEWORK = {
 'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler'
}
</code></pre>
 </div>
 
 For my example above, with the unreadable CSV file, the response would look like this:
 
 <div class="codehilite">
 <pre><code>{"status_code": 400, "detail": "Unable to read file."}
</code></pre>
 </div>
 
 With the status code returned as part of the response dictionary.
 
 
 
 Thanks to
 <a href="https://twitter.com/fwiles">
 Frank Wiles
 </a>
 for teaching me about custom exceptions, and
 <a href="https://twitter.com/webology">
 Jeff Triplett
 </a>
 for reviewing a draft of this article.
 
 
 </div>
</div>

from rest_framework import status
from rest_framework.response import Response
from rest_framework.views import APIView


class MyCSVUploadView(APIView):
    def post(self, request, *args, **kwargs):
        …
        if file_error:
            return Response(
                {"detail": "Unable to read file."}, 
                status=status.HTTP_400_BAD_REQUEST
            )

# exceptions.py
from rest_framework.exceptions import APIException


class UnreadableCSVFile(APIException):
    status_code = 400
    default_detail = "Unable to read file."
    default_code = "unreadable_csv_file"

# views.py
from rest_framework.views import APIView

From my_app.exceptions import UnreadableCSVFile

class MyCSVUploadView(APIView):
    def post(self, request, *args, **kwargs):
        …
        if file_error:
            raise UnreadableCSVFile()

from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):
    # Call REST framework's default exception handler first, 
    # to get the standard error response.
    response = exception_handler(exc, context)

    # Now add the HTTP status code to the response.
    if response is not None:
        response.data['status_code'] = response.status_code

    return response

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler'
}

{"status_code": 400, "detail": "Unable to read file."}

  
  
   With the status code returned as part of the response dictionary.
  
  
   
    Thanks to
    
     Frank Wiles
    
    for teaching me about custom exceptions, and
    
     Jeff Triplett
    
    for reviewing a draft of this article.

Custom Exceptions in Django REST Framework

When working with Wagtail, you might find that you&#x27;re using Wagtail Page models for some of your database models, but regular Django models for others. In this post, learn how to add your Django models to the Wagtail admin to make managing multiple types of models easier.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h2>
 Versions
 </h2>
 <ul>
 <li>
 Python 3.7
 </li>
 <li>
 Django 2.2
 </li>
 <li>
 Wagtail 2.6
 </li>
 </ul>
 
 When working with Wagtail, you might find that you're using Wagtail Page models for some of your database models, but regular Django models for others.
 
 
 A built-in example of this is the Django
 <code>
 User
 </code>
 model. When you log into the Wagtail admin, you can see the Django
 <code>
 User
 </code>
 model in the
 <code>
 Settings
 </code>
 submenu. The
 <code>
 User
 </code>
 model is not a Wagtail model; it's the same
 <code>
 User
 </code>
 model you see in a Django project that doesn't use Wagtail. Wagtail just exposes it to the Admin for you.
 
 </div>
</div>
<div class="w-block-content block-content">
 
 
 <img alt="users_admin.png" class="richtext-image full-width" height="360" src="https://sfo2.digitaloceanspaces.com/revsys-com-prod-media/images/users_admin.width-800.png" width="404"/>
 
 
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 We can do the same thing with our Django models: we can expose them to the Wagtail admin so we don't have to maintain two separate admin interfaces to manage our website content.
 
 
 For this example, let's assume we're working with these models:
 
 <div class="codehilite">
 <pre><code>from django.db import models 


class Pizza(models.Model):

 name = models.CharField(max_length=30)
 toppings = models.ManyToManyField("Topping")


class Topping(models.Model):

 name = models.CharField(max_length=30)
</code></pre>
 </div>
 <h2>
 Adding a single model
 </h2>
 
 The
 <a href="http://docs.wagtail.io/en/v2.6.1/reference/contrib/modeladmin/">
 Wagtail docs
 </a>
 are pretty clear on how to accomplish this, but let's walk through the steps.
 
 
 First, make sure
 <code>
 wagtail.contrib.modeladmin
 </code>
 is in your
 <code>
 INSTALLED_APPS
 </code>
 :
 
 <div class="codehilite">
 <pre><code># settings.py 

INSTALLED_APPS = [
 ...
 "wagtail.contrib.modeladmin",
]
</code></pre>
 </div>
 
 Next, in the same app as the model you want to expose to the Wagtail admin, add a file called
 <code>
 wagtail_hooks.py
 </code>
 .
 
 <div class="codehilite">
 <pre><code># wagtail_hooks.py

from wagtail.contrib.modeladmin.options import ModelAdmin, modeladmin_register 

from .models import Pizza


class PizzaAdmin(ModelAdmin):
 model = Pizza 
 menu_label = "Pizza" 
 menu_icon = "pick" 
 menu_order = 200 
 add_to_settings_menu = False 
 exclude_from_explorer = False 
 list_display = ("name",)
 list_filter = ("toppings",)
 search_fields = ("name",)


modeladmin_register(PizzaAdmin)
</code></pre>
 </div>
 
 Let's step through these options in the
 <code>
 ModelAdmin
 </code>
 class:
 
 <ul>
 <li>
 <code>
 model
 </code>
 : The name of the model you're adding.
 </li>
 <li>
 <code>
 menu_label
 </code>
 : Leave this blank to use the
 <code>
 verbose_name_plural
 </code>
 from your model. Give it a value to specify a new label for the Wagtail menu.
 </li>
 <li>
 <code>
 menu_icon
 </code>
 : Every menu item in the Wagtail admin has an icon, and you can specify the one you want to use. Here is a
 <a href="https://thegrouchy.dev/general/2015/12/06/wagtail-streamfield-icons.html">
 list of the available icons
 </a>
 .
 </li>
 <li>
 <code>
 menu_order
 </code>
 : What order you want this model to appear in. 000 is first, 100 is second, etc. Note: if you add multiple models to the admin, you won't get an error if two of them have the same
 <code>
 menu_order
 </code>
 ; Wagtail will just pick for you.
 </li>
 <li>
 <code>
 add_to_settings_menu
 </code>
 : Whether you want this menu item to appear in the
 
 Settings
 
 submenu in the Wagtail admin.
 </li>
 <li>
 <code>
 exclude_from_explorer
 </code>
 : Set to True if you
 
 do not
 
 want the explorer (the search box in the admin) to return results from this model. Set to False if you
 
 do
 
 want the explorer to return results from this model. (It's confusing.)
 </li>
 <li>
 <code>
 list_display
 </code>
 : Same as the Django admin; list the fields you want to display on the listing page for this model in the Wagtail admin.
 </li>
 <li>
 <code>
 list_filter
 </code>
 : Same as the Django admin; supply the fields you want to use to filter in the sidebar of the Wagtail admin.
 </li>
 <li>
 <code>
 search_fields
 </code>
 : Same as the Django admin; supply the fields that you want the explorer to use to return search results.
 </li>
 </ul>
 
 The final step is to register the admin class. Once you've done that and started your server, you'll be able to see your model in the Wagtail admin:
 
 </div>
</div>
<div class="w-block-content block-content">
 
 
 <img alt="pizzas_admin.png" class="richtext-image full-width" height="328" src="https://sfo2.digitaloceanspaces.com/revsys-com-prod-media/images/pizzas_admin.width-800.png" width="800"/>
 
 
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h2>
 Adding related models
 </h2>
 
 In our example models, we have two models:
 <code>
 Pizza
 </code>
 and
 <code>
 Toppings
 </code>
 . We could manually add the
 <code>
 Topping
 </code>
 model to the Wagtail admin and have it appear just below the
 <code>
 Pizza
 </code>
 model. We just learned how!
 
 
 But it's so closely related to the
 <code>
 Pizza
 </code>
 model that it might be nice if we were able to relate those two models together in a submenu, kind of like how
 
 Settings
 
 is its own submenu in the admin that contains Users, Redirects, Sites, etc.
 
 
 Go back to
 <code>
 wagtail_hooks.py
 </code>
 :
 
 <div class="codehilite">
 <pre><code># wagtail_hooks.py

from wagtail.contrib.modeladmin.options import (
 ModelAdmin, 
 ModelAdminGroup, 
 modeladmin_register 
)

from .models import Pizza, Topping


class PizzaAdmin(ModelAdmin):
 ...
 menu_order = 000 
 ...


class ToppingAdmin(ModelAdmin):
 model = Topping 
 menu_label = "Toppings" 
 menu_icon = "edit" 
 menu_order = 100 
 add_to_settings_menu = False 
 exclude_from_explorer = False 
 list_display = ("name",)
 search_fields = ("name",)
</code></pre>
 </div>
 
 Relating our two models together starts off in the same way: we create a class that inherits from
 <code>
 ModelAdmin
 </code>
 for each model and identify the necessary attributes like
 <code>
 model
 </code>
 and
 <code>
 menu_icon
 </code>
 to control things like their listing pages and search behavior.
 
 
 Then, we add a new class that inherits from
 <code>
 ModelAdminGroup
 </code>
 :
 
 <div class="codehilite">
 <pre><code># wagtail_hooks.py

from wagtail.contrib.modeladmin.options import (
 ModelAdmin, 
 ModelAdminGroup, 
 modeladmin_register 
)

from .models import Pizza, Topping


class PizzaAdmin(ModelAdmin):
 ...
 menu_order = 000 
 ...


class ToppingAdmin(ModelAdmin):
 ...
 menu_order = 100 
 ... 

class PizzaGroup(ModelAdminGroup):
 menu_label = "Pizzas" 
 menu_icon = "pick"
 menu_order = 500 
 items = (PizzaAdmin, ToppingAdmin)


modeladmin_register(PizzaGroup)
</code></pre>
 </div>
 
 In the
 <code>
 PizzaGroup
 </code>
 class, we have some of the same attributes:
 
 <ul>
 <li>
 <code>
 menu_label
 </code>
 : We set what we want this group of related models to be called in the Wagtail admin menu
 </li>
 <li>
 <code>
 menu_icon
 </code>
 : Which icon we want to use for this menu
 </li>
 <li>
 <code>
 menu_order
 </code>
 : Where we want this menu to appear in the sidebar, in relation to the other menu items
 </li>
 </ul>
 
 We also add a new attribute,
 <code>
 items
 </code>
 , where we list which
 <code>
 ModelAdmin
 </code>
 classes we want to be part of this group. In our case, we want
 <code>
 PizzaAdmin
 </code>
 and
 <code>
 ToppingAdmin
 </code>
 to be in this group, so we add those.
 
 
 Note the change we made to
 <code>
 menu_order
 </code>
 in
 <code>
 PizzaAdmin
 </code>
 and
 <code>
 ToppingAdmin
 </code>
 : Now those are set to
 <code>
 000
 </code>
 and
 <code>
 100
 </code>
 . When the
 <code>
 ModelAdmin
 </code>
 classes will be part of a group, set the
 <code>
 menu_order
 </code>
 how you want them to relate to each other, not to the other menu items in the Wagtail admin. Then set the
 <code>
 menu_order
 </code>
 for the
 <code>
 ModelAdminGroup
 </code>
 class to the proper value for the order you want it to appear in the side menu in the admin.
 
 
 Then we register the whole group, instead of the
 <code>
 ModelAdmin
 </code>
 classes individually, to the Wagtail admin. When we reload the admin, we see this:
 
 </div>
</div>
<div class="w-block-content block-content">
 
 
 <img alt="pizzas_group_admin.png" class="richtext-image full-width" height="300" src="https://sfo2.digitaloceanspaces.com/revsys-com-prod-media/images/pizzas_group_admin.width-800.png" width="800"/>
 
 
</div>
<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 On the far left, there is a new menu item
 
 Pizzas
 
 that expands a submenu. The submenu contains links to the admin interfaces for
 
 Pizzas
 
 and
 
 Toppings
 
 !
 
 
 
 Note
 
 : If you have the Django admin enabled and have your models already in the Django admin, this doesn't disable them from the regular Django admin. You are free to access your models in both the Wagtail admin and the Django admin, or at this point you can choose to remove your models from the Django admin (or disable the Django admin altogether, if you prefer).
 
 <h2>
 Helpful Links
 </h2>
 <ul>
 <li>
 <a href="http://docs.wagtail.io/en/v2.6.1/reference/contrib/modeladmin/">
 Wagtail docs on ModelAdmin
 </a>
 </li>
 <li>
 <a href="https://thegrouchy.dev/general/2015/12/06/wagtail-streamfield-icons.html">
 A List of Wagtail StreamField Icons
 </a>
 </li>
 </ul>
 
 
 Special thanks to Jeff Triplett and Jacob Burch for their help with this post.
 
 
 </div>
</div>

from django.db import models 


class Pizza(models.Model):

    name = models.CharField(max_length=30)
    toppings = models.ManyToManyField("Topping")


class Topping(models.Model):

    name = models.CharField(max_length=30)

# settings.py 

INSTALLED_APPS = [
    ...
    "wagtail.contrib.modeladmin",
]

# wagtail_hooks.py

from wagtail.contrib.modeladmin.options import ModelAdmin, modeladmin_register 

from .models import Pizza


class PizzaAdmin(ModelAdmin):
    model = Pizza 
    menu_label = "Pizza"  
    menu_icon = "pick" 
    menu_order = 200 
    add_to_settings_menu = False 
    exclude_from_explorer = False 
    list_display = ("name",)
    list_filter = ("toppings",)
    search_fields = ("name",)


modeladmin_register(PizzaAdmin)

# wagtail_hooks.py

from wagtail.contrib.modeladmin.options import (
    ModelAdmin, 
    ModelAdminGroup, 
    modeladmin_register 
)

from .models import Pizza, Topping


class PizzaAdmin(ModelAdmin):
    ...
    menu_order = 000 
    ...


class ToppingAdmin(ModelAdmin):
    model = Topping 
    menu_label = "Toppings"  
    menu_icon = "edit" 
    menu_order = 100 
    add_to_settings_menu = False 
    exclude_from_explorer = False 
    list_display = ("name",)
    search_fields = ("name",)

# wagtail_hooks.py

from wagtail.contrib.modeladmin.options import (
    ModelAdmin, 
    ModelAdminGroup, 
    modeladmin_register 
)

from .models import Pizza, Topping


class PizzaAdmin(ModelAdmin):
    ...
    menu_order = 000 
    ...


class ToppingAdmin(ModelAdmin):
    ...
    menu_order = 100 
    ... 

class PizzaGroup(ModelAdminGroup):
    menu_label = "Pizzas" 
    menu_icon = "pick"
    menu_order = 500 
    items = (PizzaAdmin, ToppingAdmin)


modeladmin_register(PizzaGroup)

  
  
   In the
   
    PizzaGroup
   
   class, we have some of the same attributes:
  
  
   
    
     menu_label
    
    : We set what we want this group of related models to be called in the Wagtail admin menu
   
   
    
     menu_icon
    
    : Which icon we want to use for this menu
   
   
    
     menu_order
    
    : Where we want this menu to appear in the sidebar, in relation to the other menu items
   
  
  
   We also add a new attribute,
   
    items
   
   , where we list which
   
    ModelAdmin
   
   classes we want to be part of this group. In our case, we want
   
    PizzaAdmin
   
   and
   
    ToppingAdmin
   
   to be in this group, so we add those.
  
  
   Note the change we made to
   
    menu_order
   
   in
   
    PizzaAdmin
   
   and
   
    ToppingAdmin
   
   : Now those are set to
   
    000
   
   and
   
    100
   
   . When the
   
    ModelAdmin
   
   classes will be part of a group, set the
   
    menu_order
   
   how you want them to relate to each other, not to the other menu items in the Wagtail admin. Then set the
   
    menu_order
   
   for the
   
    ModelAdminGroup
   
   class to the proper value for the order you want it to appear in the side menu in the admin.
  
  
   Then we register the whole group, instead of the
   
    ModelAdmin
   
   classes individually, to the Wagtail admin. When we reload the admin, we see this:
  
 


 
 
 
 
 


 
  
   On the far left, there is a new menu item
   
    Pizzas
   
   that expands a submenu. The submenu contains links to the admin interfaces for
   
    Pizzas
   
   and
   
    Toppings
   
   !
  
  
   
    Note
   
   : If you have the Django admin enabled and have your models already in the Django admin, this doesn't disable them from the regular Django admin. You are free to access your models in both the Wagtail admin and the Django admin, or at this point you can choose to remove your models from the Django admin (or disable the Django admin altogether, if you prefer).
  
  
   Helpful Links
  
  
   
    
     Wagtail docs on ModelAdmin
    
   
   
    
     A List of Wagtail StreamField Icons
    
   
  
  
   
    Special thanks to Jeff Triplett and Jacob Burch for their help with this post.

When working with Wagtail, you might find that you're using Wagtail Page models for some of your database models, but regular Django models for others. In this post, learn how to add your Django models to the Wagtail admin to make managing multiple types of models easier.

How to Add Django Models to the Wagtail Admin

On a recent project, we needed to use different serializers for GET vs POST/PUT/PATCH requests to our API. Read on to learn how we used a mixin to accomplish this goal.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 
 Versions
 
 :
 
 <ul>
 <li>
 Python 3.7
 </li>
 <li>
 Django 2.2
 </li>
 <li>
 Django REST Framework 3.10
 </li>
 </ul>
 
 On a recent project, we needed to use different serializers for GET vs. POST/PUT/PATCH requests to our Django REST Framework API. In our case, this was because the GET serializer contained a lot of nested data; for example, it contained expanded fields from other serializers to foreign-key relationships. The requests to update data via the API, though, didn't need these expanded fields.
 
 
 The first way we approached using different serializers for read and update actions was to override
 <code>
 get_serializer_class()
 </code>
 on each viewset to decide which serializer to return depending on the action in the request. We returned the "read" serializer for
 <code>
 list
 </code>
 and
 <code>
 retrieve
 </code>
 actions, and the "update" serializer for everything else. (The full list of API actions is
 <a href="https://github.com/encode/django-rest-framework/blob/335054a5d36b352a58286b303b608b6bf48152f8/rest_framework/schemas/coreapi.py#L39">
 in the DRF codebase
 </a>
 .) But we wound up repeating ourselves across several viewsets, so we wrote a mixin to take care of some of this work for us!
 
 
 A mixin is a Python class that contains custom attributes and methods (
 <a href="https://easyaspython.com/mixins-for-fun-and-profit-cb9962760556?gi=3875fd6a6ff8">
 more explanation
 </a>
 ). It's not very useful on its own, but when it's inherited into a class, that class has access to the mixin's special attributes and methods.
 
 
 This was our mixin:
 
 <div class="codehilite">
 <pre><code>class ReadWriteSerializerMixin(object):
 """
 Overrides get_serializer_class to choose the read serializer
 for GET requests and the write serializer for POST requests.

 Set read_serializer_class and write_serializer_class attributes on a
 viewset. 
 """

 read_serializer_class = None
 write_serializer_class = None

 def get_serializer_class(self): 
 if self.action in ["create", "update", "partial_update", "destroy"]:
 return self.get_write_serializer_class()
 return self.get_read_serializer_class()

 def get_read_serializer_class(self):
 assert self.read_serializer_class is not None, (
 "'%s' should either include a `read_serializer_class` attribute,"
 "or override the `get_read_serializer_class()` method."
 % self.__class__.__name__
 )
 return self.read_serializer_class

 def get_write_serializer_class(self):
 assert self.write_serializer_class is not None, (
 "'%s' should either include a `write_serializer_class` attribute,"
 "or override the `get_write_serializer_class()` method."
 % self.__class__.__name__
 )
 return self.write_serializer_class
</code></pre>
 </div>
 
 This mixin defines two new attributes,
 <code>
 read_serializer_class
 </code>
 and
 <code>
 write_serializer_class
 </code>
 . Each attribute has a corresponding method to catch the error where the mixin is being used, but those attributes haven't been set. The
 <code>
 get_*_serializer_class()
 </code>
 methods will raise an
 <code>
 AssertionError
 </code>
 if your viewset hasn't set the appropriate attribute or overridden the necessary method.
 
 
 The
 <code>
 get_serializer_class
 </code>
 method makes the final decision on which serializer to use. For the "update" actions to the API, it returns
 <code>
 write_serializer_class
 </code>
 ; otherwise it returns
 <code>
 read_serializer_class
 </code>
 .
 
 
 The mixin gets used in a viewset like this:
 
 <div class="codehilite">
 <pre><code>from rest_framework import viewsets

from .mixins import ReadWriteSerializerMixin
from .models import MyModel
from .serializers import ModelReadSerializer, ModelWriteSerializer


class MyModelViewSet(ReadWriteSerializerMixin, viewsets.ModelViewSet):
 queryset = MyModel.objects.all() 
 read_serializer_class = ModelReadSerializer 
 write_serializer_class = ModelWriteSerializer
</code></pre>
 </div>
 
 Now the viewset
 <code>
 MyModelViewSet
 </code>
 has access to the attributes and methods from the mixin
 <code>
 ReadWriteSerializerMixin
 </code>
 . This means that when a call is made to the API that uses
 <code>
 MyModelViewSet
 </code>
 , the
 <code>
 get_serializer_class()
 </code>
 method from
 <code>
 ReadWriteSerializerMixin
 </code>
 will automatically be called and will decide, based on the kind of API request being made, which serializer to use. If we needed to make even more granular decisions about the serializer returned (maybe we want to use a more limited serializer for a
 <code>
 list
 </code>
 request and one with more data in a
 <code>
 retrieve
 </code>
 request), then our viewset can override
 <code>
 get_write_serializer_class()
 </code>
 to add that logic.
 
 
 Note: Custom DRF actions will contain actions that aren't part of the DRF list of accepted actions (because they are custom actions you're creating), so when you call
 <code>
 get_serializer_class
 </code>
 from inside your action method, it will return whatever your "default" serializer class is. In the example above, the "default" serializer is the
 <code>
 read_serializer_class
 </code>
 because it's what we return when we fall through the other conditional.
 
 
 Depending on your action, you will want to override
 <code>
 get_serializer_class
 </code>
 to change your default method or explicitly account for your custom action.
 
 
 Mixins are a DRY (Don't Repeat Yourself) way to add functionality that you wind up needing to use across several viewsets. We hope you get to experiment with using them soon!
 
 
 
 Thanks to Jeff Triplett for his help with this post.
 
 
 </div>
</div>

class ReadWriteSerializerMixin(object):
    """
    Overrides get_serializer_class to choose the read serializer
    for GET requests and the write serializer for POST requests.

    Set read_serializer_class and write_serializer_class attributes on a
    viewset. 
    """

    read_serializer_class = None
    write_serializer_class = None

    def get_serializer_class(self):        
        if self.action in ["create", "update", "partial_update", "destroy"]:
            return self.get_write_serializer_class()
        return self.get_read_serializer_class()

    def get_read_serializer_class(self):
        assert self.read_serializer_class is not None, (
            "'%s' should either include a `read_serializer_class` attribute,"
            "or override the `get_read_serializer_class()` method."
            % self.__class__.__name__
        )
        return self.read_serializer_class

    def get_write_serializer_class(self):
        assert self.write_serializer_class is not None, (
            "'%s' should either include a `write_serializer_class` attribute,"
            "or override the `get_write_serializer_class()` method."
            % self.__class__.__name__
        )
        return self.write_serializer_class

from rest_framework import viewsets

from .mixins import ReadWriteSerializerMixin
from .models import MyModel
from .serializers import ModelReadSerializer, ModelWriteSerializer


class MyModelViewSet(ReadWriteSerializerMixin, viewsets.ModelViewSet):
    queryset = MyModel.objects.all() 
    read_serializer_class = ModelReadSerializer 
    write_serializer_class = ModelWriteSerializer

  
  
   Now the viewset
   
    MyModelViewSet
   
   has access to the attributes and methods from the mixin
   
    ReadWriteSerializerMixin
   
   . This means that when a call is made to the API that uses
   
    MyModelViewSet
   
   , the
   
    get_serializer_class()
   
   method from
   
    ReadWriteSerializerMixin
   
   will automatically be called and will decide, based on the kind of API request being made, which serializer to use. If we needed to make even more granular decisions about the serializer returned (maybe we want to use a more limited serializer for a
   
    list
   
   request and one with more data in a
   
    retrieve
   
   request), then our viewset can override
   
    get_write_serializer_class()
   
   to add that logic.
  
  
   Note: Custom DRF actions will contain actions that aren't part of the DRF list of accepted actions (because they are custom actions you're creating), so when you call
   
    get_serializer_class
   
   from inside your action method, it will return whatever your "default" serializer class is. In the example above, the "default" serializer is the
   
    read_serializer_class
   
   because it's what we return when we fall through the other conditional.
  
  
   Depending on your action, you will want to override
   
    get_serializer_class
   
   to change your default method or explicitly account for your custom action.
  
  
   Mixins are a DRY (Don't Repeat Yourself) way to add functionality that you wind up needing to use across several viewsets. We hope you get to experiment with using them soon!
  
  
   
    Thanks to Jeff Triplett for his help with this post.

Using Different Read and Write Serializers in Django REST Framework

Python 3.7 introduced dataclasses, which design is based on the &quot;attrs&quot; library. This article will show the way I use dataclasses and attrs, why I think you should use both, and why I think attrs is still very relevant.

def render_document(title: str, caption: str, data: List[Dict[str, Any]]):
    return template.render({
        "title" : title,
        "caption": caption,
        "data": data,
})

{
    "title": "My Table",
    "caption": "2019 Earnings",
    "data": [
        {"Period": "QT1", "Europe": 500, "USA": 467},
        {"Period": "QT2", "Europe": 345, "USA": 765},
    ]
}

def render_document(title: str, description: str, status: str, tables: List[Dict[str, Any]]):
    return template.render({
        "title": title,
        "description": description,
        "status": status,
        "tables": tables,
    })

@dataclass
class Table:
    title: str
    data: List[Dict[str, Any]]
    caption: str = ""

def render_document(title: str, description: str, tables: List[Table]):
    return template.render({
        "title": title,
        "description": description,
        "tables": tables,
    })

@attr.s
class Table(object):
    title: str = attr.ib(validator=attr.validators.instance_of(str))  # don't you pass no bytes!
    data: List[Dict[str, Any]] = attr.ib(validator=...)
    description: str = attr.ib(validator=attr.validators.instance_of(str), default="")


def render_document(title: str, description: str, tables: List[Table]):
    return template.render({
        "title": title,
        "description": description,
        "tables": tables,
    })

@dataclass
class Table:
    title: str
    data: List[Dict[str, Any]]
    caption: str = ""

@attr.s
class Document(object):
    status: str = attr.ib(validators=attr.validators.in_(
        ["draft", "in review", "approved"]
    ))
    tables: List[Table] = attr.ib(default=[])

def render_report(self, title: str, documents: List[Document]):
    return template.render({
        "title": title,
        "documents": documents,
    })

  
  
   Note how I am validating that
   
    Document.status
   
   is one of the allowed values. This comes particularly handy when you're building abstractions on top of Django models with a field that uses
   
    choices
   
   . Dataclasses can't do that.
  
  
   A couple of patterns I keep finding myself in are the following:
  
  
   
    Write a function that accepts some arguments
   
   
    Group some of the arguments into a
    
     tuple
    
   
   
    Hm, I want field names ->
    
     namedtuple
    
    .
   
   
    Hm, I want types ->
    
     dataclass
    
    .
   
   
    Hm, I want validation ->
    
     attrs
    
    .
   
  
  
   Another situation that happens quite often is this:
  
  
   
    write a function that accepts some arguments
   
   
    add typing so my IDE can help me out
   
   
    oh, by the way, it needs to support a list of those things, not just one at a time!
   
   
    refactor to use dataclasses
   
   
    This argument can only be one of those values, or
    
     
      I ask myself: How do I make sure other developers are passing the right type and/or values?
     
    
   
   
    switch to attrs
   
  
  
   Sometimes I stop at the dataclasses. Lots of times I get to the attrs step.
  
  
   And sometimes, this happens:
1. one half of this legacy codebase uses
   
    -1
   
   as special value for
   
    False
   
   , that other half uses
   
    False
   
   . Switch to
   
    attr.s
   
   so I can use
   
    converter=
   
   to normalize.
  
  
   Comparison
  
  
   The two libraries do appear very similar. To get a clearer picture of how they compare, I've made a table of the features I use most:
  
  
   
    
     
      feature
     
     
      dataclasses
     
     
      attrs
     
    
   
   
    
     
      frozen
     
     
      ✓
     
     
      ✓
     
    
    
     
      defaults
     
     
      ✓
     
     
      ✓
     
    
    
     
      totuple
     
     
      ✓
     
     
      ✓
     
    
    
     
      todict
     
     
      ✓
     
     
      ✓
     
    
    
     
      validators
     
     
      ✗
     
     
      ✓
     
    
    
     
      converters
     
     
      ✗
     
     
      ✓
     
    
    
     
      slotted classes
     
     
      ✗
     
     
      ✓
     
    
   
  
  
   As you can see, there's a lot of overlap. But the additional features on
   
    attrs
   
   provide functionality that I need more often than not.
  
  
   When to use dataclasses
  
  
   Dataclasses are just about the "shape" of the data.
Choose dataclasses if:
  
  
   
    You don't care about values in the fields, only their type
   
   
    adding a dependency is not trivial
   
  
  
   When to use attrs
  
  
   attrs is about the shape
   
    and
   
   the values.
Choose attrs if:
  
  
   
    you want to validate values. A common case would be the equivalent of a ChoiceField.
   
   
    you want to normalize, or sanitize the input
   
   
    whenever you want more formalization than dataclasses alone can offer
   
   
    you are concerned about memory and performances.
    
     attrs
    
    can create
    
     slotted classes
    
    , which are
    
     optimized by CPython
    
    .
   
  
  
   I often find myself using dataclasses and later switching to attr.s because the requirements changed or I find out I need to guard against some particular value. I think that's a normal aspect of developing software and what I call "continuous refactoring".
  
  
   Why I like dataclasses
  
  
   I'm glad dataclasses have been added to the standard library, and I think it's a beneficial addition. It's a very convenient thing to have at your disposal whenever you need.
  
  
   For one, it will encourage a more structured style of programming from the beginning.
  
  
   But I think the most compelling case is a practical one. Some high-risk corporate environments (eg: financial institutions) require every package to be vetted (with good reason: we've already had incidents of malicious code in libraries). That means that adding attrs is not as simple as adding a line to your
   
    requirements.txt
   
   , and will involve waiting on approval from your corpops team. Those developers can use dataclasses right away and their code will immediately benefit from using more formalized data types.
  
  
   Why I like attrs
  
  
   Most people don't work in such strictly-controlled environments.
  
  
   And sure, sometimes you don't need all the features from attrs, but it doesn't hurt having them.
  
  
   More often than not, I end up needing them anyway, as I formalize more and more of my code's API. Dataclasses only gets half-way of where I want to go.
  
  
   Conclusion
  
  
   I think dataclasses encompass only a subset of what attrs has to offer. Admittedly, it is a
   
    big
   
   subset. But the features that are not covered are important enough and needed often enough that they make attrs not only still relevant and useful, but also necessary.
  
  
   In my mind, using both allows developers to progressively refactor their code, moving the contracts amongst functions from loosely-defined arguments all the way up to formally described data structures as the requirements of the app stabilize over time.
  
  
   One nice effect of having dataclasses is that now developers are more incentivized to refactor their code toward more formalization. At some point dataclasses is not going to be enough, and that's when developers will refactor to use attrs. In this way, dataclasses actually acts as an
   
    introduction
   
   to attrs. I wouldn't be surprised if attrs becomes
   
    more
   
   popular thanks to dataclasses.
  
  
   References
  
  
   
    
     Documentation on dataclasses
    
    +
    
     PEP557
    
   
   
    
     Documentation on attrs
    
   
   
    
     "Why not dataclasses" on attrs' docs
    
   
  
  
   Acknowledgments + Thanks
  
  
   I want to thank the following people for revising drafts and providing input and insights:
  
  
   
    Hynek Schlawack
   
   
    Jacob Kaplan-Moss
   
   
    Jacob Burch
   
   
    Jeff Triplett

Python 3.7 introduced dataclasses, which design is based on the "attrs" library. This article will show the way I use dataclasses and attrs, why I think you should use both, and why I think attrs is still very relevant.

Dataclasses and attrs: when and why

How to smartly keep a set of Django ORM objects in order for drag-n-drop like situations.

class Task(models.Model):
 name = models.CharField(max_length=100)

class Step(models.Model):
 task = models.ForeignKey(Task, related_name='steps', on_delete=models.CASCADE)
 name = models.CharField(max_length=100)
 order = models.IntegerField(default=1)

 objects = StepManager()

from django.db import models, transaction
from django.db.models import F

class StepManager(models.Manager):
 """ Manager to encapsulate bits of business logic """

 def move(self, obj, new_order):
 """ Move an object to a new order position """

 qs = self.get_queryset()

 with transaction.atomic():
 if obj.order > int(new_order):
 qs.filter(
 task=obj.task,
 order__lt=obj.order,
 order__gte=new_order,
 ).exclude(
 pk=obj.pk
 ).update(
 order=F('order') + 1,
 )
 else:
 qs.filter(
 task=obj.task,
 order__lte=new_order,
 order__gt=obj.order,
 ).exclude(
 pk=obj.pk,
 ).update(
 order=F('order') - 1,
 )

 obj.order = new_order
 obj.save()

Step.objects.move(step_3_obj, 5)

from django.db import models, transaction
from django.db.models import F, Max

class StepManager(models.Manager):
 # ... previous code here ...

 def create(self, **kwargs):
 instance = self.model(**kwargs)

 with transaction.atomic():
 # Get our current max order number
 results = self.filter(
 task=instance.task
 ).aggregate(
 Max('order')
 )

 # Increment and use it for our new object
 current_order = results['order__max']
 if current_order is None:
 current_order = 0

 value = current_order + 1
 instance.order = value
 instance.save()

 return instance

class Step(models.Model):

 # ... original fields and manager definitions ... 

 class Meta:
 index_together = ('task', 'order')

from rest_framework import viewsets, status
from rest_framework.decorators import action
from rest_framework.response import Response
from django_filters.rest_framework import DjangoFilterBackend

from . import models
from . import serializers

class StepViewSet(viewsets.ModelViewSet):
 queryset = models.Step.objects.all().order_by('order')
 serializer_class = serializers.StepSerializer
 filter_backends = (DjangoFilterBackend, )
 filter_fields = ('task', )

 @action(methods=['post'], detail=True)
 def move(self, request, pk):
 """ Move a single Step to a new position """
 obj = self.get_object()
 new_order = request.data.get('order', None)

 # Make sure we received an order 
 if new_order is None:
 return Response(
 data={'error': 'No order given'},
 status=status.HTTP_400_BAD_REQUEST,
 )

 # Make sure our new order is not below one
 if int(new_order) < 1:
 return Response(
 data={'error': 'Order cannot be zero or below'},
 status=status.HTTP_400_BAD_REQUEST,
 )

 models.Step.objects.move(obj, new_order)

 return Response({'success': True, 'order': new_order})

 
 
 Where these endpoints reside is going to depend on how you configure things in your Django project, but assuming you're using a DRF
 
 SimpleRouter
 
 and have things setup on
 
 /api/
 
 your URL patterns are going to be something like:
 
 
 
 
 GET /api/steps/
 
 for a list of all steps
 
 
 
 GET /api/steps/?task=<task_id>
 
 for all Steps by Task (in Step order)
 
 
 
 POST /api/steps/<step_id>/move/
 
 with a JSON body of
 
 {'order': <int>}
 
 of the that Step's new order position.
 
 
 
 
 NOTE
 
 This API example excludes any authentication and authorization concerns which you will need to address before using in production. You don't want just anyone reordering your steps!
 
 
 Hopefully, you've found this informative and can put this pattern to use
in your next project. If you need help implementing things of this
nature at your company
 
 reach out to us
 
 to check on our
availability.

Keeping Django Models Ordered

ManyToManyFields confuse a lot of people. The way you relate objects to each other is just different enough from dealing with ForeignKeys and just uncommon enough in day-to-day Django development that it&#x27;s easy to forget all the little tricks for dealing with them.

from django.db import models 


class Pizza(models.Model):

 name = models.CharField(max_length=30)
 toppings = models.ManyToManyField('Topping')

 def __str__(self):
 return self.name


class Topping(models.Model):

 name = models.CharField(max_length=30)

 def __str__(self):
 return self.name

>> from pizzas.models import Pizza, Topping
>> hawaiian_pizza = Pizza.objects.create(name='Hawaiian')
>> pineapple = Topping(name='pineapple')
>> hawaiian_pizza.toppings.add(pineapple)
Traceback (most recent call last):
...
ValueError: Cannot add "<Topping: pineapple>": instance is on database "default", 
value is on database "None"
>> 

>> pineapple.save() 
>> hawaiian_pizza.toppings.add(pineapple)
>> hawaiian_pizza.toppings.all()
<QuerySet [<Topping: pineapple>]>

>> pepperoni = Topping.objects.create(name='pepperoni')
>> pepperoni_pizza = Pizza(name='Pepperoni')
>> pepperoni_pizza.toppings.add(pepperoni)
Traceback (most recent call last):
...
ValueError: "<Pizza: Pepperoni>" needs to have a value for field "id" before this many-to-many 
relationship can be used.

>> hawaiian_pizza.toppings.all()
<QuerySet [<Topping: pineapple>, <Topping: Canadian bacon>]>

>> canadian_bacon.pizzas.all()
Traceback (most recent call last):
...
AttributeError: 'Topping' object has no attribute 'pizzas'

>> canadian_bacon.pizza_set.all()
<QuerySet [<Pizza: Hawaiian>]>

class Pizza(models.Model):
 ...
 toppings = models.ManyToManyField('Topping', related_name='pizzas')

>> canadian_bacon.pizza_set.all()
<QuerySet [<Pizza: Hawaiian>]>

>> canadian_bacon.pizzas.all()
<QuerySet [<Pizza: Hawaiian>]>

>> cheese_pizza = Pizza.objects.create(name='Cheese')
>> mozzarella = Topping.objects.create(name='mozzarella')
>> mozzarella.pizzas.add(cheese_pizza)
>> mozzarella.pizzas.all()
<QuerySet [<Pizza: Cheese>]>

>> Pizza.objects.filter(toppings__name__startswith='p')
<QuerySet [<Pizza: Pepperoni Pizza>, <Pizza: Hawaiian Pizza>]>

>> Topping.objects.filter(pizzas__name__contains='Hawaiian')
<QuerySet [<Topping: pineapple>, <Topping: Canadian bacon>]>

>> pepperoni_pizza.toppings.all()
<QuerySet [<Topping: pepperoni>]>
>> pepperoni_pizza.toppings.add(pepperoni)
>> pepperoni_pizza.toppings.all()
<QuerySet [<Topping: pepperoni>]>

ValueError: Cannot alter field pizzas.Pizza.toppings into pizzas.Pizza.toppings - 
they are not compatible types (you cannot alter to or from M2M fields, or add or remove through= on M2M fields)

class ToppingAmount(models.Model):

 REGULAR = 1
 DOUBLE = 2
 TRIPLE = 3
 AMOUNT_CHOICES = (
 (REGULAR, 'Regular'),
 (DOUBLE, 'Double'),
 (TRIPLE, 'Triple'),
 )

 pizza = models.ForeignKey('Pizza', related_name='topping_amounts', on_delete=models.SET_NULL, null=True)
 topping = models.ForeignKey('Topping', related_name='topping_amounts', on_delete=models.SET_NULL, null=True, blank=True)
 amount = models.IntegerField(choices=AMOUNT_CHOICES, default=REGULAR)

class Pizza(models.Model):
 ...
 toppings = models.ManyToManyField('Topping', through='ToppingAmount', related_name='pizzas')

>> super_pep = Pizza.objects.create(name='Super Pepperoni')
>> pepperoni = Topping.objects.create(name='pepperoni')
>> super_pep.toppings.add(pepperoni)
Traceback (most recent call last):
...
AttributeError: Cannot use add() on a ManyToManyField which specifies an intermediary model. 
Use pizzas.ToppingAmount's Manager instead.

>>> super_pep_amount = ToppingAmount.objects.create(pizza=super_pep, topping=pepperoni, amount=ToppingAmount.DOUBLE)

>> super_pep.toppings.all()
<QuerySet [<Topping: pepperoni>]>

>> pepperoni.pizzas.all()
<QuerySet [<Pizza: Super Pepperoni>]>

for top_amt in ToppingAmount.objects.filter(pizza=super_pep):
 print(top_amt.topping.name, top_amt.get_amount_display())

pepperoni Double

for top_amt in super_pep.topping_amounts.all():
 print(top_amt.topping.name, top_amt.get_amount_display()) 

pepperoni Double

for topping in super_pep.toppings.all():
 for top_amt in topping.topping_amount.all():
 print(topping.name, top_amt.amount, top_amt.get_amount_display())

pepperoni 2 Double

 
 
 You could extend this
 
 ToppingAmount
 
 through model to hold information about the left and right halves of the pizza, or notes about topping preparation ("put peppers under cheese"). You can also add methods to the through model or the source/target models to more easily access some of the topping amount information.
 
 
 A through model is also useful for relationships between players and teams; the through model could contain information about the players' positions, jersey numbers, and dates they joined the team. A through model joining movie theatres and films could contain the number of screens the film is showing on and the start and end run dates. Students' relationships to their Degree Programs could track information like GPA, whether the program is the student's major or minor, whether it's a double major, and start/end semesters the student was in a program.
 
 
 
 Further Reading
 
 
 
 The
 
 many-to-many relationships
 
 section of the Django docs contains a lot of great examples of using
 
 ManyToManyField
 
 .
 
 
 The explanation of
 
 
 ManyToManyField
 
 
 in the model field reference.
 
 
 Jacob Kaplan-Moss also has a
 
 great set of examples
 
 of using a many-to-many relationship with a custom "through" model.
 
 
 
 
 Thank you to
 
 Monique Murphy
 
 and
 
 Jeff Triplett
 
 for their assistance.

ManyToManyFields confuse a lot of people. The way you relate objects to each other is just different enough from dealing with ForeignKeys and just uncommon enough in day-to-day Django development that it's easy to forget all the little tricks for dealing with them.

Tips for Using Django's ManyToManyField

A very common pattern in a Django Project is to have some kind of &#x27;model-type&#x27; relationship, where you have some kind of object that can only belong to one of the types defined in the database.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 <h1>
 Slugs as primary keys
 </h1>
 
 A very common pattern I've seen in Django Project is to have some kind of 'model-type' relationship, where you have some kind of object that can only belong to one of the types defined in the database.
 
 
 A typical implementation would look something like this:
 
 <div class="codehilite">
 <pre><code>class EventType(models.Model):
 slug = models.SlugField(unique=True)
 name = models.CharField(max_length=100)


class Event(models.Model):
 type = models.ForeignKey(EventType, on_delete=models.CASCADE)
 title = models.CharField(max_length=100)
 day = models.DateField()
</code></pre>
 </div>
 
 A subtle issue with this implementation is that you may have to query the DB for an
 <code>
 EventType
 </code>
 when creating an
 <code>
 Event
 </code>
 :
 
 <div class="codehilite">
 <pre><code>work_type = EventType.objects.get(slug='work')
Event.objects.create(
 type=work_type,
 title='release',
 day=datetime(2018, 12, 31),
)
</code></pre>
 </div>
 
 In other words, the minimum amount of queries to create an
 <code>
 Event
 </code>
 is 2: a
 <code>
 SELECT
 </code>
 for fetching the type, and the
 <code>
 INSERT
 </code>
 that saves the instance.
 
 
 If somehow you already have the
 <code>
 pk
 </code>
 of the
 <code>
 EventType
 </code>
 (for example, it might come from an API payload or from the URL), then you can easily avoid the lookup by setting the primary key directly into the
 <code>
 type_id
 </code>
 column:
 
 <div class="codehilite">
 <pre><code>def post(self, request, *args, **kwargs):
 type_id = self.kwargs['pk']
 Event.objects.create(
 type_id=type_id,
 title='release',
 day=datetime(2018, 12, 31),
 )
</code></pre>
 </div>
 
 But dealing directly with column names is
 <a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#database-representation">
 discouraged by the docs
 </a>
 
 <blockquote>
 
 However, your code should never have to deal with the database column name
 
 </blockquote>
 
 We can get around this by instantiating an
 <code>
 EventType
 </code>
 instance with just the primary key:
 
 <div class="codehilite">
 <pre><code>def post(self, request, *args, **kwargs):
 type_id = self.kwargs['pk']
 Event.objects.create(
 type=EventType(pk=type_id),
 title='release',
 day=datetime(2018, 12, 31),
 )
</code></pre>
 </div>
 
 But this requires us to know the numerical
 <code>
 id
 </code>
 beforehand.
 
 
 We already have
 <code>
 slug
 </code>
 as source of uniqueness for the
 <code>
 event_eventtypes
 </code>
 table, and it's URL-friendly. We could just use that as the
 <code>
 EventType
 </code>
 primary key.
 
 <div class="codehilite">
 <pre><code>class EventType(models.Model):
 slug = models.SlugField(primary_key=True)
 name = models.CharField(max_length=100)


class Event(models.Model):
 type = models.ForeignKey(
 EventType, 
 on_delete=models.CASCADE,
 )
 title = models.CharField(max_length=100)
 day = models.DateField()
</code></pre>
 </div>
 <div class="codehilite">
 <pre><code>def post(self, request, *args, **kwargs):
 type_slug = self.kwargs['slug']
 Event.objects.create(
 type=EventType(pk=type_slug),
 title='release',
 day=datetime(2018, 12, 31),
 )
</code></pre>
 </div>
 
 This also allows to easily create
 <code>
 Event
 </code>
 s of a specific type without having to fetching any
 <code>
 EventType
 </code>
 . This is especially useful in data migrations, or tests:
 
 <div class="codehilite">
 <pre><code>types = ['home', 'work', 'community']
for type_slug in types:
 Event.objects.create(
 type=EventType(pk=type_slug),
 title='release',
 day=datetime(2018, 12, 31),
 )
</code></pre>
 </div>
 
 In cases like this, you may want to consider using a slug as primary key, rather than the default integer-based default. It's more performant and just as straight forward.
 
 
 There are some caveat to consider, though: You won't be able to modify the slug from the Django admin.
 
 
 Another thing to consider is that changing the type of your primary key is a one-way road: once you made the slug your pk, you won't be able to convert it back to a regular
 <code>
 AutoField
 </code>
 .
 
 </div>
</div>

class EventType(models.Model):
    slug = models.SlugField(unique=True)
    name = models.CharField(max_length=100)


class Event(models.Model):
    type = models.ForeignKey(EventType, on_delete=models.CASCADE)
    title = models.CharField(max_length=100)
    day = models.DateField()

work_type = EventType.objects.get(slug='work')
Event.objects.create(
    type=work_type,
    title='release',
    day=datetime(2018, 12, 31),
)

def post(self, request, *args, **kwargs):
    type_id = self.kwargs['pk']
    Event.objects.create(
        type_id=type_id,
        title='release',
        day=datetime(2018, 12, 31),
    )

def post(self, request, *args, **kwargs):
    type_id = self.kwargs['pk']
    Event.objects.create(
       type=EventType(pk=type_id),
       title='release',
       day=datetime(2018, 12, 31),
    )

class EventType(models.Model):
    slug = models.SlugField(primary_key=True)
    name = models.CharField(max_length=100)


class Event(models.Model):
    type = models.ForeignKey(
        EventType, 
        on_delete=models.CASCADE,
    )
    title = models.CharField(max_length=100)
    day = models.DateField()

def post(self, request, *args, **kwargs):
    type_slug = self.kwargs['slug']
    Event.objects.create(
       type=EventType(pk=type_slug),
       title='release',
       day=datetime(2018, 12, 31),
    )

types =  ['home', 'work', 'community']
for type_slug in types:
    Event.objects.create(
       type=EventType(pk=type_slug),
       title='release',
       day=datetime(2018, 12, 31),
    )

  
  
   In cases like this, you may want to consider using a slug as primary key, rather than the default integer-based default. It's more performant and just as straight forward.
  
  
   There are some caveat to consider, though: You won't be able to modify the slug from the Django admin.
  
  
   Another thing to consider is that changing the type of your primary key is a one-way road: once you made the slug your pk, you won't be able to convert it back to a regular
   
    AutoField
   
   .

A very common pattern in a Django Project is to have some kind of 'model-type' relationship, where you have some kind of object that can only belong to one of the types defined in the database.

Slugs as primary keys

It is often necessary to differentiate between an argument that has not been provided, and an argument provided with the value `None`. For that purpose, we create what&#x27;s called a &#x27;sentinel value&#x27;.

<div class="w-block-markdown block-markdown">
 <div class="prose prose-lg max-w-none">
 
 Sometimes it is necessary to differentiate between an argument that has not
been provided, and an argument provided with the value
 <code>
 None
 </code>
 . For that purpose, we create what's called a 'sentinel value'.
 
 
 For example, let's assume you want to define a Field class. Field instances must have a value or declare a default,
and
 <code>
 None
 </code>
 could be a perfectly valid value to have:
 
 <div class="codehilite">
 <pre><code>class Field:
 def __init__(self, default=sentinel):
 self.value = default

 def set(self, value):
 self.value = value

 def get(self):
 if self.value is sentinel:
 raise ValueError("this field has no value!")

eula_accepted = Field()
eula_accepted.get() # raises `ValueError`

eula_accepted = Field(default=None)
eula_accepted.get() # doesn't raise. `None` means the EULA hasn't been neither accepted or reject yet.
</code></pre>
 </div>
 
 The most common approach is to declare the sentinel value with
 <code>
 object()
 </code>
 :
 
 <div class="codehilite">
 <pre><code>sentinel = object()
</code></pre>
 </div>
 
 This approach is the quickest and most common, but it has some issues. To quote
 <a href="https://mail.python.org/pipermail/python-ideas/2018-July/051852.html">
 Joseph Jevnik
 </a>
 :
 
 <blockquote>
 
 One is that they don't repr well so they make debugging harder. Another issue
is that they cannot be pickled or copied. You also cannot take a weak
reference to a sentinel which can break some caching code and makes
them harder to use.
 
 </blockquote>
 
 For example:
 
 <div class="codehilite">
 <pre><code>sentinel = object()

repr(sentinel)
# '&lt;object object at 0x10823e8d0&gt;'
</code></pre>
 </div>
 
 To work around this issue, some people create their own
 <code>
 Sentinel
 </code>
 class. But I've found a quicker way in the
 <code>
 unittest.mock
 </code>
 module.
 
 <div class="codehilite">
 <pre><code>from unittest.mock import sentinel

NotSet = sentinel.NotSet

repr(NotSet)
# 'sentinel.NotSet'
</code></pre>
 </div>
 
 If you don't feel like importing from
 <code>
 unittest
 </code>
 in your application code, you could install the
 <code>
 mock
 </code>
 package, or "hide it under the rug" by aliasing somewhere in your code base and importing it from there:
 
 <div class="codehilite">
 <pre><code># in `myproject.types`
from unittest.mock import sentinel
</code></pre>
 </div>
 <div class="codehilite">
 <pre><code># somewhere else in your project:
from myproject.types import sentinel
</code></pre>
 </div>
 
 An alternative to
 <code>
 unittest.mock.sentinel
 </code>
 is to declare your own sentinel class and use it as a value:
 
 <div class="codehilite">
 <pre><code>class NotSet:
 pass

# PS: Remember to use the class _itself_.
def fn(default=NotSet):
 pass
</code></pre>
 </div>
 
 This will give you a not really pretty, but useful enough
 <code>
 repr
 </code>
 :
 
 <div class="codehilite">
 <pre><code>repr(NotSet)
# "&lt;class '__main__.NotSet'&gt;"
</code></pre>
 </div>
 
 Of course, you could go one step further and declare your own
 <code>
 repr
 </code>
 :
 
 <div class="codehilite">
 <pre><code>class NotSet:
 def __repr__(self):
 return 'NotSet'

repr(NotSet)
# 'NotSet'
</code></pre>
 </div>
 
 Of all the options, I think using
 <code>
 unittest.mock.Sentinel
 </code>
 is my favorite. Importing from
 <code>
 unittest
 </code>
 in my application code is a compromise that I'm willing to make in exchange for having something ready to use.
 
 </div>
</div>

class Field:
 def __init__(self, default=sentinel):
 self.value = default

 def set(self, value):
 self.value = value

 def get(self):
 if self.value is sentinel:
 raise ValueError("this field has no value!")

eula_accepted = Field()
eula_accepted.get() # raises `ValueError`

eula_accepted = Field(default=None)
eula_accepted.get() # doesn't raise. `None` means the EULA hasn't been neither accepted or reject yet.

sentinel = object()

sentinel = object()

repr(sentinel)
# '<object object at 0x10823e8d0>'

from unittest.mock import sentinel

NotSet = sentinel.NotSet

repr(NotSet)
# 'sentinel.NotSet'

# in `myproject.types`
from unittest.mock import sentinel

# somewhere else in your project:
from myproject.types import sentinel

class NotSet:
 pass

# PS: Remember to use the class _itself_.
def fn(default=NotSet):
 pass

repr(NotSet)
# "<class '__main__.NotSet'>"

class NotSet:
 def __repr__(self):
 return 'NotSet'

repr(NotSet)
# 'NotSet'

 
 
 Of all the options, I think using
 
 unittest.mock.Sentinel
 
 is my favorite. Importing from
 
 unittest
 
 in my application code is a compromise that I'm willing to make in exchange for having something ready to use.

It is often necessary to differentiate between an argument that has not been provided, and an argument provided with the value `None`. For that purpose, we create what's called a 'sentinel value'.

Sentinel values in Python

In this post, you will learn how to create a Celery task inside a Django project in a Docker container. Sounds awesome, right?

proj/
├── app/
 ├── __init__.py
 ├── tasks.py
├── proj/
 ├── __init__.py
 ├── celery.py
 ├── settings.py
├── docker-compose.yml
├── Dockerfile
├── manage.py
└── requirements.txt

celery==4.2.1
redis==2.10.6

import os
from celery import Celery


os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')

app = Celery('proj')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()

@app.task(bind=True)
def debug_task(self):
 print('Request: {0!r}'.format(self.request))

from celery import shared_task


@shared_task
def hello():
 print(“Hello there!”) 

from .celery import app as celery_app

__all__ = ['celery_app']

>>> from app.tasks import hello
>>> hello()
Hello there! 

>>> hello.delay()
<AsyncResult: ba845cf3-e60b-4432-a9d8-9943621cb8a0>

CELERY_BROKER_URL = 'redis://redis:6379'
CELERY_RESULT_BACKEND = 'redis://redis:6379'
CELERY_ACCEPT_CONTENT = ['application/json']
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'

from celery.schedules import crontab

CELERY_BEAT_SCHEDULE = {
 'hello': {
 'task': 'app.tasks.hello',
 'schedule': crontab() # execute every minute
 }
}

version: '3'

services:
 db:
 image: postgres:9.6.5
 volumes:
 - postgres_data:/var/lib/postgresql/data/
 redis:
 image: "redis:alpine"
 web:
 build: .
 command: bash -c "python /code/manage.py migrate --noinput && python /code/manage.py runserver 0.0.0.0:8000"
 volumes:
 - .:/code
 ports:
 - "8000:8000"
 depends_on:
 - db
 - redis
 celery:
 build: .
 command: celery -A proj worker -l info
 volumes:
 - .:/code
 depends_on:
 - db
 - redis
 celery-beat:
 build: .
 command: celery -A proj beat -l info
 volumes:
 - .:/code
 depends_on:
 - db
 - redis

volumes:
 postgres_data:

redis:
 image: "redis:alpine"

depends_on:
 - db
 - redis

celery:
 build: .
 command: celery -A proj worker -l info
 volumes:
 - .:/code
 depends_on:
 - db
 - redis

celery-beat:
 build: .
 command: celery -A proj beat -l info
 volumes:
 - .:/code
 depends_on:
 - db
 - redis

celery_1 | [2018-02-01 22:44:00,957: WARNING/ForkPoolWorker-1] Hello there!

 
 
 And there you have it! For even more fun, you might try:
 
 
 
 Adding more complex tasks, like tasks that take arguments
 
 
 Setting up different schedules
 
 
 Setting up a non-periodic task
 
 
 
 What next?
 
 
 Review the
 
 Celery Tasks Checklist
 
 for a great introduction to Celery best practices. In particular, pay attention to:
 
 
 
 Set a
 
 retry_limit
 
 so that failed tasks don’t keep trying forever.
 
 
 Set a high default
 
 task_time_limit
 
 to avoid tasks that block the entire Celery worker.
 
 
 For tasks that need to take in a Django model object as a parameter, pass in a primary key and not the object itself.
 
 
 Do a lot of logging!
 
 
 
 You will also want to monitor your tasks for success or failure. A great tool for this is
 
 Flower
 
 , Celery’s monitoring tool. Flower will show you a dashboard of all your workers and tasks and let you drill down into specific tasks, show you task statistics, let you restart workers, and let you rate-limit tasks (among many other things).
 
 
 If you use an error-tracking system like
 
 Rollbar
 
 or
 
 Sentry
 
 , you can also set Celery up to report exceptions to those services.
 
 
 Further Reading
 
 
 
 
 Celery Task Checklist
 
 
 
 
 Message Queues and Async Workers
 
 , Frank Wiles
 
 
 
 Celery Docs - Periodic Tasks
 
 
 
 
 Celery Docs - First steps with Django
 
 
 
 
 Celery Docs - task_always_eager
 
 
 
 
 Celery Docs - Logging
 
 
 
 
 Celery 4 Periodic Task in Django
 
 , Yehan Djoehartono
 
 
 
 Asynchronous Tasks with Django and Celery
 
 (Celery 3.1.18)
 
 
 
 
 * Thanks to
 
 kurashu89
 
 for their correction on an earlier version of this article.

Celery and Django and Docker: Oh My!

django-test-plus has long been a useful helper library with Django. Now we&#x27;ve added some simple pytest fixture support to make it even more useful!

<div class="w-block-content block-content">
 
 We're obviously fans of
 <a href="https://github.com/revsys/django-test-plus">
 django-test-plus
 </a>
 , having written it, and have found it very valuable over the last few years at cutting down on all of the boilerplate test code we have to write with our clients.
 
 
 
 
 It even helps sell certain stubborn clients on the idea that testing can be done in a not so painful way!
 
 
 Today we're happy to announce that you can now use django-test-plus as a real pytest fixture. Here's a quick example:
 
</div>
<div class="w-block-code block-code">
 <div class="codehilite">
 <pre>def test_some_view(tp):
 tp.get('some-view-name')
 tp.response_200()


def test_some_url_stuff(tp):
 expected_url = '/api/'
 reversed_url = tp.reverse('api')
 assert expected_url == reversed_url
</pre>
 </div>
</div>
<div class="w-block-content block-content">
 
 And you get all of the other test plus methods as part of that "tp" fixture. This is a new experimental feature, so we'd love to hear how we can make this better and more "pytest like".
 
 
 
 
 To start using all you need to do is install it and pull in "tp" as a fixture, you install it with just:
 
</div>
<div class="w-block-code block-code">
 <div class="codehilite">
 <pre>pip install django-test-plus
</pre>
 </div>
</div>

def test_some_view(tp):
    tp.get('some-view-name')
    tp.response_200()


def test_some_url_stuff(tp):
    expected_url = '/api/'
    reversed_url = tp.reverse('api')
    assert expected_url == reversed_url

 
pip install django-test-plus

django-test-plus has long been a useful helper library with Django. Now we've added some simple pytest fixture support to make it even more useful!

Hello, Python

Python Jobs 💼