El sabor de Django nos entusiasma y atrae

Han pasado varias semanas desde el lanzamiento oficial de la versión 3 de Django. Trabajé con esta versión incluso antes de la publicación del lanzamiento oficial y, desafortunadamente, noté que el desarrollo de Django se desaceleró significativamente. La versión 1.3 a veces difiere de la 1.7, pero la versión 3 contiene cambios cosméticos en la rama 2 y nada más.

Mi proyecto winePad comenzó con Django 1.3, y ahora ha redefinido alrededor del 12% del código interno de Django.

Al ver el código para la nueva versión, entiendo que las ediciones que yo o mis colegas hicimos mientras trabajaban con versiones anteriores irán más allá. Pero mirando la hoja de ruta y los lentos cambios en el repositorio oficial, no tenemos que esperar a que los errores se corrijan en futuras versiones.

Esto es de lo que quiero hablar sobre trabajar en errores:

Obtener el método

Pocas personas se dan cuenta de que hubo un error en el método get django estándar desde el principio. El método get debería devolverle un objeto, advertirle que se encontraron varios objetos o informar que no hay objetos.

1 def get(self, *args, **kwargs): 2 clone = self._chain() if self.query.combinator else self.filter(*args, **kwargs) 3 if self.query.can_filter() and not self.query.distinct_fields: 4 clone = clone.order_by() 5 limit = None 6 if not clone.query.select_for_update or connections[clone.db].features.supports_select_for_update_with_limit: 7 limit = MAX_GET_RESULTS 8 clone.query.set_limits(high=limit) 9 num = len(clone) 10 if num == 1: 11 return clone._result_cache[0] 12 if not num: 13 raise self.model.DoesNotExist() 14 raise self.model.MultipleObjectsReturned() 

La línea 9 recibe datos de TODOS los registros que se especifican en el conjunto de consultas y los traduce en un conjunto de objetos. Hay una advertencia sobre esto en la documentación.

Antes de la versión 3, no había límite en el número de objetos solicitados. Esto significa que recibe absolutamente todos los datos y los convierte en objetos, antes de advertir que hay muchos objetos.

Como resultado, podría obtener varios millones de objetos en la memoria, solo para descubrir que se encontró más de 1 objeto. Ahora hay líneas 5,7,8. Y ahora con orgullo solo obtienes MAX_GET_RESULTS = 21 objetos antes de saber que hay más de 1 objetos.
Con "__init__" pesado el retraso será significativo. Cómo tratar:
Anular MAX_GET_RESULTS en django.db.models.query.py
anular GET o antes de llamar a GET use:

 vars(queryset.query).update({'high_mark':2, 'low_mark':0})  queryset.query.set_limits(0,2) 

Método __Init__ de modelos Django

La declaración en el código del método incorporado __init__ no está del todo clara

 _setattr=setattr 

Esto es probablemente para seudo-endurecer el código mediante la transferencia de la referencia de función al diccionario local, pero no se trata de eso. Hay varios problemas:

1. Si pasa pares de atributos = valores adicionales en el modelo __init__, obtendrá "un argumento de palabra clave inesperado".

En este caso, sugiero no cargar el método __init__, sino agregar atributos después de la inicialización:

 obj = MyClass() vars(obj).update({'attr':val, 'attr2':val2 ...}) 

2. El nuevo Django agregó la capacidad de redefinir descriptores en cualquier campo del modelo (Field.descriptor_class). Pero ni un solo descriptor sabe si el objeto se inicializa o no. Esto es necesario, por ejemplo, si el descriptor utilizará datos de objetos prefetch_related que aparecerán solo después de la inicialización del objeto principal.

No me gusta usar la señal del final de la inicialización, porque puede haber muchos suscriptores.

En este caso, no se me ocurrió nada más inteligente que anular __init__ y agregar un atributo para finalizar la inicialización.

  def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self._end_init = True 

Conjuntos de consultas

El EmptyQuerySet / DateQuerySet codificado se ha eliminado, ya está bien. Sin embargo, la situación con queryset como administrador ideológicamente no me gusta.

Si deseo anular la clase QuerySet creada por los administradores, agrego el atributo _queryset_class

 class MyManager(models.Manager): _queryset_class = MyQuerySet 

Atención, para versiones anteriores esto no funciona, por ejemplo, puede hacer esto:

 class MyManager(models.Manager): def get_query_set(self): response = super(MyManager, self).get_query_set() response.__class__ = MyQuerySet return response 

panel de administración de inlineFormset

Hay varios problemas:

1. No es posible mostrar registros estándar en línea de conjunto de formularios que no tienen una conexión directa con el objeto de formulario principal. Por ejemplo: un formulario para editar precios de productos. En el medio se encuentra la forma estadística de referencia Tabularinline de los precios de compra al por mayor para bienes "similares".

Se resuelve anulando el método del modelo en línea get_formset y creando su propio MyFormSet heredado de BaseInlineFormSet

 def get_formset(self, request, obj=None, **kwargs): kwargs['formset'] = MyFormSet super().get_formset(request, obj, **kwargs) class MyFormSet(BaseInlineFormSet): pass 

2. Si está editando un objeto con un conjunto de formularios en línea en el panel de administración, y en este momento alguien eliminará uno de los registros de objetos dentro del conjunto de formularios en línea a través de otro mecanismo, recibirá un error y no podrá guardar el objeto. Solo a través de kopy paste en una nueva ventana del navegador.

Hasta ahora solo he encontrado una solución: no use inlineformset.

Panel de administración

La "característica asesina" de Django, es el cactus más grande del proyecto:

1. La acción "Eliminar objetos" en los administradores de modelos es visible de forma predeterminada, no importa si el usuario tiene derechos para eliminar o no.

Se resuelve deshabilitando esta acción por defecto:

 admin.site.disable_action('delete_selected') 

2. No será posible crear derechos de usuario adicionales desde el panel de administración hasta que habilite el administrador del modelo Permisos:

 from django.contrib.auth.models import Permission class PermissionsAdmin(admin.ModelAdmin): search_fields = ('name', 'codename','content_type__app_label', 'content_type__model') list_display = ('name', 'codename',) actions = None admin.site.register(Permission, PermissionsAdmin) 

3. Desgraciadamente, el derecho a acceder solo a ciertos objetos en Django no existe.

Esto se puede resolver escribiendo una entrada en djangoAdminLog con un indicador especial.
Y luego verifique la bandera:

 user.logentry_set.filter(action_flag=ENABLED, .....).exists() 

4. Si crea acciones de administrador como se describe en la documentación, recuerde que no se registran automáticamente en djangoAdminLog.

5. Otro inconveniente de esta parte de la documentación es que todos los ejemplos son solo sobre funciones. ¿Pero qué hay de GCBV? En mis proyectos, todas las acciones de los administradores de modelos se transfieren a GCBV. Repositorio.

La conexión de acción es estándar:

 class MyAdmin(admin.ModelAdmin): actions = (MyActionBasedOnActionView.as_view(),) 

ContentType - registro de modelo django

50% de genio / 50% de opacidad.
Ninguno de los modelos tiene acceso al registro de modelo predeterminado.
En nuestros proyectos, se resuelve agregando un mixin a todas las clases:

 from django.contrib.contenttypes.models import ContentType class ExportMixin(object): @classmethod def ct(cls): if not hasattr(cls, '_ct'): cls._ct, create = ContentType.objects.get_or_create(**cls.get_app_model_dict()) if create: cls._ct.name = cls._ct.model._meta.verbose_name cls._ct.save() return cls._ct @classmethod def get_model_name(cls): if not hasattr(cls, '_model_name'): cls._model_name = cls.__name__.lower() return cls._model_name @classmethod def get_app_name(cls): if not hasattr(cls, '_app_name'): cls._app_name = cls._meta.app_label.lower() return cls._app_name @classmethod def get_app_model_dict(cls): if not hasattr(cls, '_format_kwargs'): cls._format_kwargs = {'app_label': cls.get_app_name(), 'model': cls.get_model_name()} return cls._format_kwargs 

ahora podemos llamar a obj.ct () si es necesario.

Modelo de usuario

La capacidad de anular el modelo de usuario apareció en la versión 1.5.

Pero para la versión 3, no arreglaron model = User en el estándar UserCreationForm / UserChangeForm.
Se resuelve:

 from django.contrib.auth.forms import UserCreationForm from django.contrib.auth import get_user_model class MyUserCreationForm(UserCreationForm): class Meta: model= get_user_model() 

Sistema de traducción

Las etiquetas visibles para el usuario están etiquetadas

 {% trans %} 

o en código a través de

 gettext_lazy 

Sin embargo, no hay administración de estos recursos en el panel de administración. En general

Hay soluciones externas, todas funcionan de alguna manera.

Por ejemplo, Rosetta pierde sistemáticamente los textos y la interfaz funciona con errores. No hay verificación de los derechos de acceso a las traducciones en ningún lugar. Se necesitan mensajes de compilación / mensajes sistemáticos para trabajar ...

En winePad, las etiquetas trans, blocktrans y gettext_lazy se redefinieron y comenzamos a recibir textos del caché. Si no hay caché, la solicitud almacenada en caché de la base get_or_create también nos salvó de los mensajes de creación.

El tema del multilingüismo es generalmente complicado. La solución integrada de Django solo funciona para textos estáticos. Pero todavía es necesario traducir estos modelos. Intenté a mi manera resolver el problema de traducir textos dinámicos en el proyecto django-TOF , donde combiné las capacidades de traducción de modelos y Parler / Hvad. Probablemente alguien estará interesado en mirar.

Por ahora, detendré la narrativa, ya que el artículo de corrección de errores de Django podría convertirse fácilmente en un hilo largo.

Por favor, dime cómo estás mejorando tu Django. Si hay una continuación, sistematizo las ideas que han surgido.

ps Algunos códigos están escritos en la antigua notación, espero entender, no siempre se encuentra el tiempo o el personal para la refactorización.