django's .extra (où = les clauses sont tabassées par un changement de table .filter (foo__in = ... subselects

Question

En résumé, les noms des tables de toutes les requêtes qui se trouvent dans un filtre sont renommés en u0, u1,. .., donc mes clauses supplémentaires where ne sauront pas à quelle table pointer.Je n'aimerais pas avoir à faire toutes les requêtes pour chaque façon que je pourrais sous-sélectionner sur ces données, et ma solution de contournement actuelle est de tourner mon extra d requêtes dans pk values_lists, mais ceux-ci sont vraiment lents et quelque chose d'une abomination

Voici à quoi tout cela ressemble.Vous pouvez ignorer les détails de ce qui se passe dans les extra de cette méthode de gestionnaire, sauf le premier sql ligne qui pointe vers products_product.id:

def by_status(self, *statii): 
    return self.extra(where=["""products_product.id IN                                     
     (SELECT recent.product_id                                           
      FROM (                                               
      SELECT product_id, MAX(start_date) AS latest                                     
      FROM products_productstatus                                          
      GROUP BY product_id                                            
     ) AS recent                                              
      JOIN products_productstatus AS ps ON ps.product_id = recent.product_id                               
      WHERE ps.start_date = recent.latest                                        
      AND ps.status IN (%s))""" % (', '.join([str(stat) for stat in statii]),)]) 

Ce qui fonctionne à merveille pour toutes les situations impliquant uniquement la table products_product.

Quand je veux que ces produits en tant que sous-sélection, je fais:

Piece.objects.filter(
    product__in=Product.objects.filter(
     pk__in=list(
      Product.objects.by_status(FEATURED).values_list('id', flat=True)))) 

Comment puis-je conserver les capacités générales d'un ensemble de requêtes, mais utilisent encore un supplément where?

Answer 1

Au début, le problème n'est pas totalement clair pour moi. Le deuxième bloc de code de votre question est-il le code que vous voulez exécuter? Si tel est le cas, la requête devrait fonctionner comme prévu, car aucune sous-sélection n'est effectuée.

Je suppose que vous voulez utiliser le deuxième bloc de code sans le list() autour de la sous-sélection pour empêcher une deuxième requête en cours d'exécution. La documentation django fait référence à ce numéro in the documentation about the extra method. Cependant, ce n'est pas très facile de surmonter ce problème. La solution la plus facile mais la plus «hakish» consiste à observer quel alias de table est produit par django pour la table que vous voulez interroger dans la méthode supplémentaire. Vous pouvez compter sur la dénomination persistante de cet alias tant que vous construisez la requête toujours de la même manière (vous ne modifiez pas l'ordre des multiples méthodes extra ou filter qui provoquent une jointure).

Vous pouvez inspecter une requête qui sera exécuter dans le queryset DB en utilisant:

print Model.objects.filter(...).query 

Cela révélera les alias utilisés pour les tables que vous souhaitez interroger.