Las Novedades Que Trae Django 5 – Parte 2 (Final)

7 minuto(s)

En esta página:

En la parte anterior pudimos ver grupos de ciertas características que trae Django 5, como los Filtros de facetas en el administrador, Valores predeterminados calculados por la base de datos, asimismo las nuevas caraterísticas menores como el nuevo método AdminSite.get_log_entries() que permite personalizar el conjunto de consultas para los logs o registros del sitio y otras característias más que puedes ver la Parte 1. En esta segunda parte continuaremos viendo Las Novedades Que Trae Django 5 (Final), vamos con ello.

Partes

Parte 1
Parte 2

Diseño de un software — Uno de los procesos iniciales en la construcción de un Software en el diseño del mismo

Antes de continuar te invito a leer los siguientes artículos:

Asimismo, te invito a escuchar el Podcast: “Con Que Lenguaje De Programación Comenzar Para El Desarrollo Web” y “¿ Se Debe Escuchar Música Mientras Se Programa ?” (Spotify for Podcasters):

Spotify:	Sound Cloud:	Apple Podcasts	Spotify for Podcasters

Bien ahora continuemos con el Post: Las Novedades Que Trae Django 5 – Parte 2 (Final).

Cambios incompatibles con versiones anteriores en 5.0

A continuación veamos las incomptabilidades que tendrá Django 5 con versiones anteriores de Django:

API back-end de base de datos

Es necesario que los desarrolladores back-end realicen los siguientes cambios para sus bases de datos en Django:

En la clase DatabaseFeatures debe establecerse supports_expression_defaults en False si es que la base de datos no permite el uso de métodos de base de datos como valores predeterminados. Sintaxis referencial completa: DatabaseFeatures.supports_expression_defaults.
En la clase DatabaseFeatures debe establecerse supports_default_keyword_in_insert en False si la base de datos no admite la palabra clave DEFAULT en las consultas INSERT. Sintaxis referencial completa: DatabaseFeatures.supports_default_keyword_in_insert.
En la clase DatabaseFeatures debe establecerse supports_default_keyword_in_bulk insert en False si la base de datos no admite la palabra clave DEFAULT en consultas masivas INSERT. Sintaxis referencial completa: DatabaseFeatures.supports_default_keyword_in_bulk insert.

Soporte eliminado para las versiones de MySQL menores a 8.0.11

En Django 5 se elimina el soporte para versiones preliminares de la serie MySQL 8.0.x. Django 5 solo será compatible con MySQL 8.0.11 y superior.

django.contrib.gis

En este módulo para crear aplicaciones geoespaciales en Django:

Se elimina el soporte para GDAL 2.2 y 2.3 (GDAL son las iniciales de Geospatial Data Abstraction Library).
Se elimina la compatibilidad con GEOS 3.6 y 3.7 (GEOS son las iniciales de Geometry Engine – Open Source).

django.contrib.sitemaps

Esta herramienta o framework incorporado en Django que permite crear mapas de sitio en un sitio o aplicación web recibe las siguientes actualizaciones:

La función django.contrib.sitemaps.ping_google() y el comando de administración ping_google se eliminan ya que el endpoint de ping de Google Sitemaps está obsoleto y se eliminará en enero de 2024.
La clase de excepción django.contrib.sitemaps.SitemapNotFound es eliminada.

Puedes leer más acerca del anuncio de Google en este enlace: El endpoint “ping” de los sitemaps va a dejar de estar disponible.

Cuando se usa el parámetro create_defaults__exact es posible que ahora sea necesario usarse con el método QuerySet.update_or_create()

El método QuerySet.update_or_create() ahora admite el parámetro create_defaults. Como consecuencia, cualquier modelo que tenga un nombre de campo create_defaults que se use con un método update_or_create() debe especificar el campo en la búsqueda con el parámetro create_defaults__exact.

Migración de UUIDField a MariaDB 10.7+

En MariaDB 10.7+, el campo UUIDField ahora se crea como una columna UUID en lugar de una columna CHAR(32). Como consecuencia, cualquier UUIDField creado en Django < 5.0 debe reemplazarse con una subclase UUIDField respaldada por CHAR(32):


class Char32UUIDField(models.UUIDField):
    def db_type(self, connection):
        return "char(32)"

class Char32UUIDField(models.UUIDField):

def db_type(self, connection):

return "char(32)"

Por ejemplo:


class MiModelo(models.Model):
    uuid = models.UUIDField(primary_key=True, default=uuid.uuid4)

class MiModelo(models.Model):

uuid = models.UUIDField(primary_key=True, default=uuid.uuid4)

Debe convertirse a:


class Char32UUIDField(models.UUIDField):
    def db_type(self, connection):
        return "char(32)"


class MiModelo(models.Model):
    uuid = Char32UUIDField(primary_key=True, default=uuid.uuid4)

class Char32UUIDField(models.UUIDField):

def db_type(self, connection):

return "char(32)"

class MiModelo(models.Model):

uuid = Char32UUIDField(primary_key=True, default=uuid.uuid4)

Si se ejecuta el comando makemigrations que permite generar migraciones en Django, generará una migración que contiene una operación AlterField no operativa.

Varios

Veamos a continuación una variedad de novedades en Django 5:

Se cambia el nombre del argumento instance del método no documentado a .BaseModelFormSet.save_existing()obj
El indocumentado helper django.contrib.admin.helpers.checkbox es eliminado.
Los campos enteros ahora se validan como enteros de 64 bits en SQLite para que coincidan con el comportamiento de sqlite3.
El atributo no documentado Query.annotation_select_mask se cambia de un conjunto de strings a una lista ordenada de strings.
El método ImageField.update_dimension_fields() ya no se llama en la señal o signal post_init si los parámetros width_field y height_field no están configurados.
La función de base de datos Now ahora usa LOCALTIMESTAMP en lugar de CURRENT_TIMESTAMP en base de datos Oracle.
Dentro del encabezado de la interface AdminSite.site_header ahora el texto se representa en una etiqueta <div> en lugar de la etiqueta <h1>. Los usuarios de lectores de pantalla confían en los elementos de encabezado para navegar dentro de una página. Tener dos elementos <h1> era confuso y el encabezado del sitio no era útil, ya que se repite en todas las páginas.
Las bases de datos sin soporte nativo para el operador SQL: ^ (XOR), ahora devuelven filas que coinciden con un número impar de operandos en lugar de exactamente un operando. Esto es consistente con el comportamiento de MySQL, MariaDB y Python.
La versión mínima admitida del módulo asgirefse se incrementa de 3.6.0 a 3.7.0.
La versión mínima admitida para el entorno de pruebas selenium se incrementa de 3.8.0 a 4.8.0.
Las excepciones AlreadyRegistered y NotRegistered se mueven de django.contrib.admin.sites a django.contrib.admin.exceptions.
La versión mínima admitida de SQLite aumentó de 3.21.0 a 3.27.0.

Sabías que la base de datos MariaDB esta desarrollada sobre los lenguajes de programación C, C++, Perl y la interfaz de línea de comandos Bash.

Métodos en desuso

Ya no se podrá usar las siguientes funciones o métodos:

Los renderizadores de formas de transición DjangoDivFormRenderer y Jinja2DivFormRenderer están en desuso.
Pasar argumentos posicionales name y violation_error_message a la clase BaseConstraint está obsoleto en favor de argumentos de solo palabras clave.
El método get_joining_columns() de las clases ForeignObject y ForeignObjectRel está en desuso. A partir de Django 6, django.db.models.sql.datastructures.Join ya no recurrirá al método get_joining_columns(). Las subclases deberían implementar el método get_joining_fields() en su lugar.
El método ForeignObject.get_reverse_joining_columns() esta en desuso.
El esquema predeterminado para los campos de tipo URL forms.URLField de una base de datos cambiará de “http“a “https”en Django 6.
Se eliminará el soporte para llamar al método format_html() sin pasar argumentos o kwargs.

Funciones eliminadas

Las siguientes características han llegado al final de su ciclo de obsolescencia y son eliminadas:

La configuración de prueba SERIALIZE es eliminada.
El módulo no documentado django.utils.baseconv se elimina.
El django.utils.datetime_safemódulo no documentado se elimina.
El valor predeterminado de la configuración USE_TZ se cambia de False a True.
El protocolo de mapa de sitio predeterminado para los mapas de sitio creados fuera del contexto de una solicitud se cambia de ‘http‘ a ‘https‘.
El argumento extra_tests a favor del método DiscoverRunner.build_suite() y DiscoverRunner.run_tests() se elimina.
Los agregados django.contrib.postgres.aggregates.ArrayAgg, JSONBAgg y StringAgg ya no devuelven [] y ”, respectivamente, cuando no hay filas.
El ajuste USE_L10N se elimina.
Se elimina la configuración de transición USE_DEPRECATED_PYTZ.
Se elimina la compatibilidad con las zonas horarias pytz.
El argumento is_dst se elimina de los siguientes métodos:
- QuerySet.datetimes()
- django.utils.timezone.make_aware()
- django.db.models.functions.Trunc()
- django.db.models.functions.TruncSecond()
- django.db.models.functions.TruncMinute()
- django.db.models.functions.TruncHour()
- django.db.models.functions.TruncDay()
- django.db.models.functions.TruncWeek()
- django.db.models.functions.TruncMonth()
- django.db.models.functions.TruncQuarter()
- django.db.models.functions.TruncYear()
Las clases django.contrib.gis.admin.GeoModelAdmin y OSMGeoAdmin se eliminan.
El método no documentado BaseForm._html_output() se elimina.
Se elimina la capacidad de devolver un str, en lugar de un SafeString, al representar un ErrorDict y ErrorList.
Se elimina el método SitemapIndexItem.__str__().
Se elimina la configuración de transición CSRF_COOKIE_MASKED.
Se elimina el argumento name del decorador django.utils.functional.cached_property().
Se elimina el argumento opclasses del método django.contrib.postgres.constraints.ExclusionConstraint.
Se elimina la capacidad indocumentada de pasar errors=None a los métodos SimpleTestCase.assertFormError() y assertFormsetError().
El método django.contrib.sessions.serializers.PickleSerializer es removido.
Ya no se permite el uso del método QuerySet.iterator() en un conjunto de consultas que precarga objetos relacionados sin proporcionar el argumento chunk_size.
Ya no se permite pasar instancias de modelo no guardadas a filtros relacionados.
created=True se requiere en la firma de las subclases RemoteUserBackend.configure_user().
Se eliminó el soporte para cerrar sesión a través de solicitudes GET en los métodos django.contrib.auth.views.LogoutView y django.contrib.auth.views.logout_then_login().
Se elimina el alias django.utils.timezone.utc para la clase datetime.timezone.utc.
Pasar un objeto de respuesta y un nombre de form/formset a la SimpleTestCase.assertFormError() y assertFormSetError() ya no está permitido.
Se elimina la clase django.contrib.gis.admin.OpenLayersWidget.
Se elimina la clase django.contrib.auth.hashers.CryptPasswordHasher.
Las plantillas “django/forms/default.html” y “django/forms/formsets/default.html“se eliminan.
El estilo de representación predeterminado de formularios y conjuntos de formularios se cambia a basado en div.
Pasar nulls_first=False o nulls_last=False a los métodos Expression.asc() y Expression.desc(), y a la expresión OrderBy ya no está permitido.

Consulta las Funciones obsoletas en Django 4 y Django 4.1 para obtener detalles sobre estos cambios, incluido cómo eliminar el uso de estas funciones.

Conclusión

En este post que consta de 2 partes, te he compartido a detalle las nuevas funciones, características y cambios que traerá la versión 5 de Django. Si es que vienes de Django 4 u otra versión anterior, espero que hayas leído todos estos cambios, ya que tu próximo proyecto con Django te puede dar algún error por algun cambio en la versión.