2009-03-05 5 views
0

Le problème n'était pas lié au problème tel qu'il est présenté ci-dessous. Voir le bas du message pour une explication. Merci.Le gestionnaire renvoie des objets de modèle une fois par demande (le gestionnaire supprime les objets après les avoir renvoyés une fois)


Bonjour,

Je suis actuellement le comportement connaît que le défaut Manager pour un modèle particulier renvoie les objets pour ce modèle une seule fois par la demande ou par session shell. Voici une transcription APB de l'arrêt dans une vue (mais le problème se produit sans PDB, aussi):

#Nothing up my sleeves (using the default Manager): 
(Pdb) p Entry.objects 
<django.db.models.manager.Manager object at 0x18523b0> 

#Now you see them... 
(Pdb) Entry.objects.all() 
[<Entry: Entry 1>, <Entry: Entry 2>, <Entry: Entry 3>, <Entry: Entry 4] 

#Now you don't! 
(Pdb) Entry.objects.all() 
[] 

Chaque fois que je récupère un objet, cet objet ne figure plus dans QuerySets plus tard.

#(New Request from above) 

#If I only request one object then it is the one that disappears 
(Pdb) Entry.objects.all()[0] 
[<Entry: Entry 1>] 

#Here Entry 1 is missing 
(Pdb) Entry.objects.all() 
[<Entry: Entry 2>, <Entry: Entry 3>, <Entry: Entry 4] 

#And now they're all gone. 
(Pdb) Entry.objects.all() 
[] 

Ce comportement est réservé à un de mes modèles; les autres modèles semblent interroger correctement. Je ne pense pas que cela ait quelque chose à voir avec ma définition de modèle, qui est basiquement:

class Entry(models.Model): 
    user = models.ForeignKey(User, related_name='entries') 
    blog = models.ForeignKey(Blog, related_name='entries') 
    positive = models.BooleanField() 

Je suis désolé que ma description est un peu vague; Je suis confus sur la façon dont ce comportement pourrait survenir et je ne sais pas où fouiller ensuite.

Le SQL généré par le gestionnaire pour le QuerySet est le même (et apparemment correct) à chaque fois:

(Pdb) p Entry.objects.all().query.as_sql() 
('SELECT "myapp_entry"."id", "myapp_entry"."user_id", "myapp_entry"."blog_id", "myapp_entry"."positive" FROM "myapp_entry"',()) 
(Pdb) p Entry.objects.all() 
[<Entry: Entry 1>, <Entry: Entry 2>, <Entry: Entry 3>, <Entry: Entry 4] 

(Pdb) p Entry.objects.all().query.as_sql() 
('SELECT "myapp_entry"."id", "myapp_entry"."user_id", "myapp_entry"."blog_id", "myapp_entry"."positive" FROM "myapp_entry"',()) 
(Pdb) Entry.objects.all() 
[] 

J'utilise Django 1.0.2, Python 2.6.1, et qui est venu SQLite emballé avec Python 2.6.1 sur une machine Mac OS 10.5.

En réponse à l'un des commentaires que j'ai essayé de renommer les pour éviter un éventuel conflit paramètres related_name à entries1 et entries2 mais cela n'a pas changé le comportement.


SOLVED (je pense)

Désolé tout, le problème était en fait sans rapport avec le problème que je l'ai présenté. J'ai eu un bug négligente dans un de mes signaux sur l'entrée:

En myapp.__init__:

post_init.connect(entry_initialized, sender=Entry) 

En myapp.signals:

def entry_initialized(sender, instance, *args, **kwargs): 
    try: 
     #Disconnect signal to avoid infinite recursion 
     post_init.disconnect(entry_initialized, sender=Entry) 

     #Intializing a new Entry here would cause the recursion 
     #Check to see if there is a previous entry by this user in this blog 
     #In this app entries are unique by (User, Blog) 
     #And what we want to do is remove the old Entry if the positive fields don't match 
     prev_instance = Entry.objects.get(user=instance.user, blog=instance.blog) 

     #This is an error: it is not appropriate to delete without some checking 
     prev_instance.delete() 

     post_init.connect(verification_initialized, sender=Verification) 
    except: 
     post_init.connect(verification_initialized, sender=Verification) 

La version correcte de mon code serait:

 #Only delete if this is a different Entry with same user/blog and the positive field is different. 
     if not instance.id == prev_instance and not instance.positive == prev_instance.positive: 
      prev_instance.delete() 
+0

Oui, c'est un gratte-tête :) Est-ce que le gestionnaire de modèle est le gestionnaire par défaut? Si c'est un gestionnaire personnalisé, vous devrez poster la source au gestionnaire quelque part. En outre, il peut être utile de regarder la requête générée, c'est-à-dire, qs = Entry.objects.all(); print qs.sql –

+0

Étrange. Rien de mal avec le modèle. Même si je voudrais jeter un coup d'oeil au code du gestionnaire si ce n'est pas celui par défaut. Veuillez le coller. – simplyharsh

+0

peut-être même related_name = 'entries' affecte en quelque sorte, ils devraient être defferent autant que je sache – user20955

Répondre

0

Désolé tout le problème était en fait sans rapport avec le problème que je l'ai présenté.J'ai eu un bug négligente dans un de mes signaux sur l'entrée:

En myapp.__init__:

post_init.connect(entry_initialized, sender=Entry) 

En myapp.signals:

def entry_initialized(sender, instance, *args, **kwargs): 
    try: 
     #Disconnect signal to avoid infinite recursion 
     post_init.disconnect(entry_initialized, sender=Entry) 

     #Intializing a new Entry here would cause the recursion 
     #Check to see if there is a previous entry by this user in this blog 
     #In this app entries are unique by (User, Blog) 
     #And what we want to do is remove the old Entry if the positive fields don't match 
     prev_instance = Entry.objects.get(user=instance.user, blog=instance.blog) 

     #This is an error: it is not appropriate to delete without some checking 
     prev_instance.delete() 

     post_init.connect(verification_initialized, sender=Verification) 
    except: 
     post_init.connect(verification_initialized, sender=Verification) 

La version correcte de mon code serait:

 #Only delete if this is a different Entry with same user/blog and the positive field is different. 
     if not instance.id == prev_instance and not instance.positive == prev_instance.positive: 
      prev_instance.delete() 
Questions connexes