Modelos.py
class Material(BaseModelClass): material = models.CharField(max_length=25, verbose_name='Material') def __str__(self): return self.material class PurOrder(BaseModelClass): order_number = models.CharField(max_length=25) class PurOrderItem(BaseModelClass): order = models.ForeignKey(PurOrder, on_delete=models.CASCADE) material = models.ForeignKey(Material, on_delete=models.PROTECT)Creé un formulario PurOrder y un conjunto de formularios PurOrderItem
PurOrderForm = modelform_factory(PurOrder, fields=('order_number',)) PurOrderFormset = inlineformset_factory(PurOrder, PurOrderItem,fields=('material',))Los inicializó de la siguiente manera.
form = PurOrderForm(instance=order_instance) queryset = order_instance.purorderitem_set.all().select_related('material',) formset = PurOrderFormset(instance=order_instance, queryset=queryset)Esta configuración me cuesta 22 consultas si hay 20 PurOrderItem para purorder seleccionado.
Piénselo, si hay 1000 PurOrderItem
Con el select_related proporcionado, agrega material a PurOrderItemselect, pero cuando se trata de mostrarlo, creo que vuelve a consultar.
Uso django-autocomplete-light, por lo que me evita consultar todas las instancias de material, pero sigue consultando el material seleccionado, para mostrarlo aunque selecciono material_relacionado.
Idealmente, seleccionaría la instancia PurOrder con purorderitem precargado y materiales relacionados, esto significa 3 consultas. Se utilizarán artículos y materiales precargados cuando sea su turno.
Por favor, aconséjeme una forma de evitar la consulta de opciones seleccionadas.
Nota: trato de evitar el almacenamiento en caché aquí.
ACTUALIZAR
Mucho tiempo después de que creé esta pregunta y probé las soluciones proporcionadas. El problema es que los formularios de formset no se conocen entre sí. Por lo tanto, siempre que las búsquedas relacionadas con el conjunto de consultas o relacionadas con la captación previa no se pasen a los formularios del conjunto de formularios.
Estás bien. Este código te costará solo 3 consultas. Como puede ver en la documentación de select_related() :
Devuelve un QuerySet que "seguirá" las relaciones de clave externa, seleccionando datos adicionales de objetos relacionados cuando ejecuta su consulta. Este es un refuerzo de rendimiento que da como resultado una consulta única más compleja, pero significa que el uso posterior de relaciones de clave externa no requerirá consultas de base de datos.
Significa que su código realizará una mysql join y dará como resultado un conjunto de datos con todos los datos. Por eso, puedo ver que su código es bastante bueno.
Le sugiero que use algún tipo de perfil como django-silk para ver cuántas consultas se generan.
Nota:
Como puede ver en la documentación de prefetch_related() , la diferencia entre prefetch_related() y select_related() está en la forma en que realizan la unión:
Esto ( prefetch_related ) tiene un propósito similar a select_related , en el sentido de que ambos están diseñados para detener la avalancha de consultas a la base de datos causada por el acceso a objetos relacionados, pero la estrategia es bastante diferente.
...
select_related funciona creando una unión SQL e incluyendo los campos del objeto relacionado en la instrucción SELECT. Por esta razón, select_related obtiene los objetos relacionados en la misma consulta de base de datos.
...
prefetch_related , por otro lado, realiza una búsqueda separada para cada relación y realiza la 'unión' en Python.
Entonces, siempre que necesite una relación one-to-one , select_related es la forma más eficiente de consultar la relación.
Recientemente me di cuenta de que el problema en un caso similar no eran los conjuntos de formularios, el problema eran los {{formset.errors}} en la plantilla, ya que cada conjunto de formularios generaba una consulta para esto.