2011-06-20 4 views
1

J'essaie de suivre la documentation pour les recherches qui couvrent les relations pour une relation "inverse", trouvé here. Voici mon code modèle:Django "Recherches qui couvrent les relations" Erreur

class Foo(models.Model): 
    initiator = models.ForeignKey(User) 
    date_time = models.DateTimeField() 
    ... 

Et voici mon code de requête:

... 
now = datetime.now() 
users = User.objects.filter(foo__date_time__gte = now) 
... 

Il en résulte l'erreur suivante: django.core.exceptions.FieldError: Impossible de résoudre le mot-clé 'foo' dans champ. Les choix sont: _message_set, date_joined, email, prenom, groupes, id, is_active, is_staff, is_superuser, last_login, last_name, logentry, mot de passe, user_permissions, nom d'utilisateur

Cependant, si je change mon code pour ne pas utiliser l'utilisateur, mais Au lieu de cela, utilisez mon propre type de barre, alors tout fonctionne comme je le souhaiterais sans erreur. Exemple ci-dessous:

class Foo(models.Model): 
    initiator = models.ForeignKey(Bar) 
    date_time = models.DateTimeField() 
    ... 

... 
now = datetime.now() 
bars = Bar.objects.filter(foo__date_time__gte = now) 
... 

Quelqu'un peut-il me expliquer le problème avec le premier code qui utilise le modèle de l'utilisateur comme clé étrangère? Merci d'avance!

EDIT: Je dois préciser que mon code de requête n'est pas dans une fonction de vue, mais dans une fonction utilitaire que j'appelle à l'aide d'une commande manage.py. Si je mets le code de requête dans une vue alors tout fonctionne bien sans erreur! Mais la chose curieuse est que le deuxième exemple de code fonctionne bien dans les scénarios de vue et de gestion.

J'espère que quelqu'un avec un peu plus d'expertise Django que moi peut l'expliquer. Merci!

+0

Avez-vous ajouté l'application dans laquelle 'Foo' est défini dans' INSTALLED_APPS'? –

+0

Merci pour votre réponse Daniel. Oui, mon application est dans INSTALLED_APPS. J'ai édité mon article original pour clarifier que ce code n'est pas dans une fonction de vue, et cela semble faire une différence, bien que je ne sois pas tout à fait sûr pourquoi. – Blade

Répondre

3

Ok, problème résolu! Cela semble être un détail incroyablement minuscule qui causait ce problème, et je ne peux pas dire que je comprends parfaitement pourquoi il s'est manifesté comme il l'a fait, mais voici:

J'ai eu from django.contrib.auth.admin import UserAdmin en haut de mon models.py, le long avec mes autres déclarations d'importation. Il ne me restait plus qu'à refacturer mon admin dans son propre admin.py, donc l'import UserAdmin n'était pas utilisé du tout dans models.py. J'ai commenté cette instruction inutilisée, puis j'ai effectué une syncdb et obtenu une erreur de validation de modèle sur un nom de requête inversé qui était en conflit (c'était dans un champ ForeignKey dans mon modèle User Profile, mais pas le modèle que je ne pouvais pas interroger dans ma question initiale). J'ai donc ajouté un argument related_name à ce champ, fait un syncdb, exécuté ma requête initiale qui donnait des erreurs précédemment, et tout fonctionnait sans erreur! Donc à la fin, il s'est résumée à from django.contrib.auth.admin import UserAdmin errant.

Merci à tous ceux qui ont répondu en essayant d'aider!