Introduction to the Full stack

1. Understanding Full-stack development
Welcome to the full-stack development with Django learning series. This topic aims to help the reader understand what it actually means to be a full-stack developer. First, let's discuss the role of a full-stac...

Read: https://franklynose.hashnode.dev/introduction-to-the-full-stack

Django security releases issued: 4.2.3, 4.1.10, and 3.2.20

In accordance with our security release policy, the Django team
is issuing Django 4.2.3, Django 4.1.10, and Django 3.2.20.
These releases addresses the security issue detailed below. We encourage all
users of Django to upgrade as soon as possible.
CVE-2023-36053: Potential regular expression denial of service vulnerability in EmailValidator/URLValidator

EmailValidator and URLValidator were subject to potential regular
expression denial of service attack via a very large number of domain name
labels of emails and URLs.

Thanks Seokchan Yoon for reports.

This issue has severity "moderate" according to the Django security policy.
Affected supported versions

* Django main branch
* Django 4.2
* Django 4.1
* Django 3.2
Resolution

Patches to resolve the issue have been applied to Django's main branch and the
4.2, 4.1, and 3.2 release branches. The patches may be obtained from the
following changesets:

* On the main branch
* On the 4.2 release branch
* On the 4.1 release branch
* On the 3.2 release branch

The following releases have been issued:

* Django 4.2.3 (download Django 4.2.3 | 4.2.3 checksums)
* Django 4.1.10 (download Django 4.1.10 | 4.1.10 checksums)
* Django 3.2.20 (download Django 3.2.20 | 3.2.20 checksums)

The PGP key ID used for this release is Mariusz Felisiak: 2EF56372BA48CD1B.
General notes regarding security reporting

As always, we ask that potential security issues be reported via
private email to [email protected], and not via Django's
Trac instance or the django-developers list. Please see our security
policies for further
information.

Read: https://www.djangoproject.com/weblog/2023/jul/03/security-releases/

Дайджест Python #12: взлом ChatGPT и оптимизация Jupyter Notebook

Собрали лучшие материалы по Python с 15 по 30 июня. Узнайте, как взломать ChatGPT и как компилировать типизированный Python.

Читать: «Дайджест Python #12: взлом ChatGPT и оптимизация Jupyter Notebook»

What happens behind the scene in Django? Understand the request/response cycle of Django.

In the world of web development, Django has emerged as a powerful framework for building robust and scalable web applications. As you dive into Django, it's essential to understand how the framework handles incoming requests and generates appropriate...

Read: https://faithbolanle.hashnode.dev/what-happens-behind-the-scene-in-django-understand-the-requestresponse-cycle-of-django

Google Authentication in Django

Hello Internet Programmers. Let’s add google authentication in Django projects. We will use django-allauth packege. Okay, let’s jump into the code.
We are continuing from the previous tutorial: Django-allauth Customizing form templates and adding CSS...

Read: https://ifiokambrose.hashnode.dev/google-authentication-in-django

How to add/Migrate SQLite to PostGres SQL in your Django project

To add PostgreSQL as the database backend for your Django project, you'll need to follow these steps:
Step 1: Install the Required Packages Make sure you have the necessary packages installed. You'll need psycopg2, which is the PostgreSQL adapter for...

Read: https://ifiokambrose.hashnode.dev/how-to-addmigrate-sqlite-to-postgres-sql-in-your-django-project

Get and Post methods using Flask, Django, and FastAPI

HTTP provides different methods for communication between a client and a server. In the article, we're going to decode the basics of get and post methods using various Python frameworks.

Introduction
HTTP methods, also known as HTTP verbs, are an in...

Read: https://therareblogle.hashnode.dev/get-and-post-methods-using-flask-django-and-fastapi

PyCharm & DSF Campaign 2023

The Django Software Foundation’s biggest fundraising event of the year is here!

https://www.jetbrains.com/pycharm/promo/support-django/

Each year, our friends at JetBrains, the creators of PyCharm, run an incredible deal. You get a 30% discounted year of PyCharm, AND the DSF gets 100% of the proceeds. Plus, get one free month of access to JetBrains Academy, which has courses like Intro to Django, SQL, Git, and more!

The fundraiser runs from July 3rd-July 23rd! Buy PyCharm and support Django!

Donations like this fundraiser allow the DSF to function. Our two wonderful Fellows, Mariusz Felisiak and Natalia Bidart keep Django running smoothly. In 2022, our Fellows (Carlton Gibson and Mariusz) were instrumental in:

* Releasing 25 Django versions, including 4.1 and the preparation for 4.2
* Maintaining security: 10 CVEs were identified and patched in a timely manner
* Triaging hundreds of new issues
* Managing and supporting the community through mailing lists and forums

In the past, JetBrains through the PyCharm fundraiser has provided approximately one quarter of the Django Software Foundation’s budget! Remember, get your discounted year of PyCharm now, and the DSF will receive 100% of proceeds!

The other side of the DSF is our support for Django groups across the globe. We have supported each of the DjangoCons held across the globe, particularly with donating funding towards opportunity grants for more people to be able to attend these conferences. The DSF also supports smaller events around the world, including DjangoGirls events.

2023 is off to a great start where we hope to do more with your help!

Finally, I want to tell you about PyCharm itself.

PyCharm is an integrated development environment (IDE) that helps professional Python web developers be more productive, be more confident, and write better code. It supports the full Python web workflow out of the box, including popular Python web frameworks, such as Django, frontend technologies, and databases.

Here are the main benefits of using PyCharm in your Django development:

* The built-in Django run/debug configuration type makes it easy to configure and start the Django server.
* Syntax and error highlighting, code completion, navigation between views and templates, ability to debug templates visually by inserting a breakpoint right in the editor.
* Special coding assistance within standard files: urls.py and settings.py: files, folders, view methods, regex injection and highlighting. Utilize intentions to let PyCharm create views and templates from usage.
* Autocompletion for static resource names in templates, special interactive task window for manage.py with project-driven autocomplete, Jinja and Mako templates in Django, code intentions such as convert function view to/from class-based view, template inspections to warn for mistakes, i18n helpers, live templates for Django, model diagrams, and more.

Get Django work done with PyCharm, a powerful IDE tailored for Django web development!

Consider this the easiest charitable donation you will ever make, when you get such a great product in return!

If you would like to donate in another way, especially if you are already a PyCharm customer, here are other ways to donate to the DSF:

On our website via credit card: https://www.djangoproject.com/fundraising/

Via GitHub sponsors: https://github.com/sponsors/django

For those able to make a larger donation, particularly corporate sponsors, more information: https://www.djangoproject.com/foundation/corporate-membership/ and application: https://www.djangoproject.com/foundation/corporate-membership/join/

Thank you,

Catherine Holmes

DSF Assistant

Read: https://www.djangoproject.com/weblog/2023/jul/03/pycharm-dsf-campaign-2023/

Advanced Django Cheat Sheet

This article was originally posted to my personal blog

Be aware it's not an exhaustive list.
If you have ideas, correction or recommendation do not hesitate and do so on Github or in the comments section.
Sections

Preparing environnement
Creating a...

Read: https://julienc.hashnode.dev/advanced-django-cheat-sheet

How to integrate stripe to Django

Step 1: Install the required packages
Ensure that you have the necessary packages installed. You can use pip to install them:
pip install stripe
pip install djstripe

Step 2: Configure Django settings
Open your Django project's settings file (setting...

Read: https://ifiokambrose.hashnode.dev/how-to-integrate-stripe-to-django

Road-Map for Python Developers

Should I learn Python? Some weeks ago, someone asked me if Python is good for beginners.
I ponder the questions above and figured many people still have no idea what programming language to use.
The fact that new evolving languages constantly bomba...

Read: https://learnhubafrica.hashnode.dev/road-map-for-python-developers

DJANGO-sign in page with OTP verification via email

While learning a framework ,creating mini projects helps us to explore the features of the framework.Now,we are going to create a simple sign-in page with email verification using Django.At the end of this blog,you will get an insight about the djang...

Read: https://pythongeek.hashnode.dev/django-sign-in-page-with-otp-verification-via-email

Django-Dynamic HTML page creation with image(user profile page )

In this blog,we are going to create a log-in page for our page and we will create a dynamic html page for displaying user’s profile and personal details whoever logs in.Displaying user uploaded images inside an app along with user details is explaine...

Read: https://pythongeek.hashnode.dev/django-dynamic-html-page-creation-with-imageuser-profile-page

Creating Open-Source Resources for The Community (Ep 2)

Mastori, as the name implies, is a platform where community members can share their blogs and articles. The name "Mastori" originates from Kenyan slang, sheng, meaning "many stories." Our vision is to provide a space for individuals to write about to...

Read: https://spaceyatech.hashnode.dev/creating-open-source-resources-for-the-community-ep-2

Mastering Django CI/CD using GitHub Actions

Testing and delivery is a common repetitive cycle in application development. This cycle consumes more time and resources as we fix or add more features to our application. Automating this repetitive process will reduce the time spent in application ...

Read: https://thecodeway.hashnode.dev/mastering-django-cicd-using-github-actions

Интеграция Django с материализованными представлениями PostgreSQL

Django  —  один из самых популярных веб-фреймворков, написанных на Python. Он следует принципу “Не повторяйся” (DRY) и быстро решает задачи веб-разработки с помощью набора инструментов, библиотек и соглашений.

Действительно продвинутым Django делает встроенная поддержка ORM (механизма объектно-реляционного отображения), который разрабатывает команда Django. Модель данных в Django представлена в виде классов Python, в которых можно создавать и запрашивать таблицы базы данных без использования необработанных SQL-запросов.

В этой статье мы рассмотрим, как интегрировать Django с материализованными представлениями PostgreSQL. Настроим ORM Django на полную поддержку материализованных представлений, определив модели материализованных представлений в проекте Django таким образом, чтобы изменения модели могли быть обнаружены системой миграции Django.

Что такое материализованные представления?

Представления в движках баз данных  —  это виртуальные таблицы, предоставляющие возможность выполнять запросы и получать данные из существующих таблиц. Они позволяют упростить процесс выполнения сложных запросов. Однако использование представлений, динамически выполняющих первичный запрос (primary query) при каждом обращении, может идти в ущерб производительности.

Именно здесь в игру вступают материализованные представления. В отличие от обычных, материализованные представления хранят результаты базового запроса в физической таблице. Другими словами, материализованные представления компилируют результаты запроса и сохраняют их как отдельную сущность в базе данных. Поэтому получить доступ к материализованным представлениям можно намного быстрее, чем к обычным представлениям, предполагающим повторное выполнение запроса при каждом обращении.

При этом необходимо учитывать некоторые недостатки материализованных представлений.

1. Данные в материализованных представлениях могут устаревать, если не обновлять их регулярно, что может привести к несоответствиям.
2. Необходимо учитывать требования к хранению, поскольку материализованные представления потребляют дисковое пространство для хранения данных.
3. Материализованные представления добавляют сложности системе, так как требуют обслуживания при обновлении базовых таблиц.

Создание материализованного представления в PostgreSQL

Материализованное представление можно создать с помощью следующей команды SQL:
CREATE MATERIALIZED VIEW popular_posts AS
SELECT * FROM posts WHERE rating > 200;
Этот запрос создаст новое материализованное представление из базового запроса с кэшированным результатом. При этом обновленные данные в исходной таблице не будут автоматически доступны в материализованном представлении, так как их нужно будет обновить вручную с помощью следующей команды:
REFRESH MATERIALIZED VIEW popular_posts;
Эта команда обновит материализованное представление и заполнит свежими данными базовую таблицу, а также перекомпилирует определение базового запроса материализованного представления.

Проблема

Поскольку в настоящее время ORM Django поддерживает только таблицы баз данных, мне стало интересно, можно ли настроить ORM Django для поддержки материализованных представлений. Проведя исследование, я понял, что можно добиться этого несколькими способами, но не был удовлетворен ни одним решением, так как ни одна из настроек не могла полностью поддерживать материализованные представления для использования в качестве моделей Django.

Одно из решений предполагало создание пустого файла миграции вручную и указание SQL-запроса для создания материализованного представления с помощью команды RunSQL.
from django.db import migrations

class Migration(migrations.Migration):

dependencies = [
("api", "0001_initial"),
]

operations = [
migrations.RunSQL(
sql="CREATE MATERIALIZED VIEW popular_posts AS SELECT * FROM posts WHERE rating > 200",
reverse_sql="DROP MATERIALIZED VIEW popular_posts"
)
]

Кроме того, нео[...]

бходимо создать класс модели, определив поля точно так же, как и в запросе материализованного представления. Класс модели должен иметь:

* опцию managed, которую нужно установить в false в определении мета-класса для указания того, что схема базы данных не должна управляться Django, чтобы предотвратить создание новой таблицы системой миграции;
* опцию db_table, которая должна быть явно установлена в соответствии с именем материализованного представления.
class PopularPosts(models.Model):
title = models.CharField(max_length=200)
content = models.TextField()
author = models.ForeignKey(User, on_delete=models.CASCADE)
tag_names = models.CharField(max_length=200)
created_at = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)
rating = models.PositiveIntegerField()

class Meta:
managed = False
db_table = 'popular_posts'
На мой взгляд, данный подход не является оптимальным решением, эффективным в долгосрочной перспективе, особенно при частых обновлениях или изменениях атрибутов класса модели. Когда потребуется изменение атрибутов класса модели, нужно переписывать новый необработанный запрос в новом файле миграции, что может занять много времени и чревато ошибками. Более того, это может стать громоздкой задачей, особенно по мере роста и развития приложения с течением времени.

Как интегрировать Django с материализованными представлениями

Чтобы интегрировать Django с материализованными представлениями, в нашем примере будет применено несколько настроек.

* Создание пользовательского класса модели.
* Создание пользовательского класса поля модели.
* Создание пользовательского движка базы данных для PostgreSQL.
* Соединение всего созданного в проекте.

Шаг 1. Создание пользовательского класса модели

Первым шагом к интеграции Django с материализованными представлениями в PostgreSQL является создание пользовательского класса модели с целью сообщить Django, что модель предназначена для материализованного представления.

Существует несколько способов определить, является ли класс модели материализованным представлением. Я создал класс модели таким образом, чтобы он принимал два пользовательских атрибута класса Meta внутри класса модели.

* materialized_viewуказывает, что класс модели является материализованным представлением, а не таблицей.
* view_parent_modelуказывает классу модели, какой реальный класс модели должен использоваться, чтобы создать базовый запрос для материализованного представления.
class MaterializedViewModel(models.Model):

class Meta:
materialized_view = True
view_parent_model = 'app_label.Model'
Обычно Django не позволяет определять пользовательские атрибуты своего класса Meta внутри классов модели, выдавая исключение TypeError:
raise TypeError(
TypeError: 'class Meta' got invalid attribute(s): materialized_view
Проведя исследование, я обнаружил, что в Django можно использовать только атрибуты Meta, которые статически определены в кортеже DEFAULT_NAMES, который находится в модуле django.db.models.options. Чтобы устранить это ограничение, я применил обходной путь, импортировав модуль options и переопределив переменную DEFAULT_NAMESв файле __init__.pyмодуля проекта перед наполнением приложений Django. Эта модификация обеспечивает поддержку пользовательских атрибутов в классе Meta.
# djangoProject/__init__.py

import django.db.models.options as options

options.DEFAULT_NAMES += ('materialized_view', 'view_parent_model',)
Шаг 2. Создание пользовательского поля модели

Следующий шаг  —  создание пользовательского поля модели, специально предназначенного для класса модели материализованного представления, которое будет иметь два пользовательских атрибута. Каждое из пользовательских полей, указанных в классе модели, впоследствии будет преобразовано в необработанные SQL-запросы для генерации SQL, что необходимо для создания материализованного представления.
from[...]

django.db.models import fields
from django.db.models.expressions import Combinable, ExpressionWrapper, F

class MaterializedViewField(fields.Field):
def __init__(self, child, source=None, **kwargs):
super().__init__(**kwargs)
self.child = child

if isinstance(source, Combinable) or source is None:
self.source = source

elif isinstance(source, str):
self.source = ExpressionWrapper(F(source), output_field=child)

else:
self.source = None

def deconstruct(self):

"""
Переопределение метода deconstruct для включения атрибутов пользовательских полей в файлы миграции
при выполнении команды `makemigrations` в отншении модели материализованного представления.

"""

name, path, args, keywords = super().deconstruct()

keywords.update(
source=self.source, child=self.child
)
return name, path, args, keywords
Шаг 3. Создание пользовательского движка базы данных для PostgreSQL

Следующий шаг  —  создание пользовательского движка базы данных с пользовательским классом редактора. Этот движок отвечает за реализацию необходимой настройки схемы.

Чтобы настроить редактор схем баз данных Django, нужно определить новый движок базы данных в проекте и сослаться на него в атрибуте ENGINEзаписи DATABASESв файле настроек проекта.

Обратите внимание: пользовательский движок базы данных нужно поместить в каталог с файлом base.pyи классом DatabaseWrapper.

За дополнительной информацией обратитесь к документации Django.

Ниже приведен пример структуры папок, где движок базы данных помещен в приложение Django под названием core и в подпапку backends.
project_root/
...
django_project/
__init__.py
settings.py

core/
__init__.py
backends/
__init__.py
db/
__init__.py
base.py
Следующий код является примером пользовательского движка базы данных (он расположен в файле base.py).
from django.apps import apps
from django.db.backends.postgresql import base
from django.db.models import QuerySet, options, Model

from api.fields import MaterializedViewField

class DatabaseSchemaEditor(base.DatabaseSchemaEditor):
sql_create_materialized_view = "CREATE MATERIALIZED VIEW %(table)s AS %(definition)s"
sql_delete_materialized_view = "DROP MATERIALIZED VIEW %(table)s"
sql_refresh_materialized_View = "REFRESH MATERIALIZED VIEW %(concurrently)s %(view)s"

@staticmethod
def model_meta(model: type[Model]) -> options.Options:
return model._meta

def _get_parent_model(self, model: type[Model]):
"""
Возвращает базовую модель представления, которая будет использоваться для генерации SQL материализованного представления.
"""
parent_model = getattr(self.model_meta(model), 'view_parent_model', None)

if parent_model:
return apps.get_model(*parent_model.split('.'))

def model_is_materialized_view(self, model: type[Model]) -> bool:
"""Проверяет, является ли класс модели моделью материализованного представления или обычной моделью django."""
return getattr(self.model_meta(model), 'materialized_view', False)

def get_queryset(self, model: Model, extra_field=None):
"""Генерирует набор запросов из предоставленной родительской модели и предоставленных полей."""

def append_field(_model_field):

if _model_field.source is None:
concrete_fields.append(_model_field.name)
else:
annotation_fields.update({_model_field.attname: _model_field.source})

concrete_fields = []
annotation_fields = dict()

for field_name, field in model.__dict__.items():
if hasattr(field, 'field'):
model_field: MaterializedViewField = field.field

if isinstance(model_field, MaterializedViewField):
append_field(model_field)

if extra_field:
append_field(extra_field)

return QuerySet(
model=self._get_parent_model(model)
).only(*concrete_fields).annotate(**annotation_fields).query

def create_model(self, model, extra_field=None):
if self.model_is_materialized_view(model):
sql = self.sql[...]