2009-03-05 2 views
0

Das Verhalten steht in keinem Zusammenhang mit dem Problem, wie unten dargestellt. Eine Erläuterung finden Sie am Ende des Beitrags. Vielen Dank.Manager gibt einmal pro Anforderung Modellobjekte zurück (Manager löscht Objekte, nachdem sie einmal zurückgegeben wurden)


Hallo,

ich derzeit erlebt das Verhalten, dass die Standard-Manager für ein bestimmtes Modell nur einmal die Objekte für dieses Modell gibt pro Anfrage oder per Shell-Sitzung. Nachfolgend finden Sie eine PDB-Transkript in einer Ansicht von Stoppen (aber das Verhalten ohne PDB auftritt, auch):

#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() 
[] 

Immer wenn ich ein Objekt abzurufen, das Objekt wird nicht mehr in späteren QuerySets.

#(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() 
[] 

Dieses Verhalten ist nur für eines meiner Modelle; die anderen Modelle scheinen korrekt abzufragen. Ich glaube nicht, dass es etwas mit meinem Modell Definition zu tun, die basicaly ist:

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

Ich entschuldige mich, dass meine Beschreibung ein wenig vage ist; Ich bin verwirrt darüber, wie dieses Verhalten entstehen könnte und nicht sicher, wo ich als nächstes herumstochern soll.

Die vom Manager generierten SQL für die QuerySet ist das gleiche (und korrekt scheinbar) jedes Mal: ​​

(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() 
[] 

Ich verwende Django 1.0.2, Python 2.6.1 und die SQLite, die kamen mit Python 2.6.1 auf einem Mac OS 10.5-Rechner gepackt.

Als Antwort auf eine der Kommentare, die ich die related_name Parameter entries1 Umbenennung versucht und entries2 einen möglichen Konflikt zu vermeiden, aber das hat nicht das Verhalten ändern.


GELÖST (glaube ich)

Leider allem war das Problem, um das Problem tatsächlich in keinem Zusammenhang, wie ich es dargestellt. Ich hatte einen sorglosen Fehler in einem meiner Signale auf Entry:

In myapp.__init__:

post_init.connect(entry_initialized, sender=Entry) 

In 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) 

Die richtige Version von meinem Code wäre:

 #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

Ja, das ist ein Kopffehler :) Ist der Modellmanager der Standard? Wenn es sich um einen benutzerdefinierten Manager handelt, müssen Sie die Quelle irgendwo an den Manager senden. Es kann auch hilfreich sein, die erzeugte Abfrage zu betrachten, d. H. Qs = Entry.objects.all(); Drucken qs.sql –

+0

Seltsam. Nichts ist falsch mit dem Modell. Auch ich würde gerne Manager Code sehen, wenn es nicht der Standard ist. Bitte fügen Sie es ein. – simplyharsh

+0

vielleicht selbe related_name = 'Einträge' beeinflussen irgendwie, sollten sie so weit ich weiß unterscheiden – user20955

Antwort

0

Sorry alle, das Problem war eigentlich nicht verwandt mit dem Problem, wie ich es vorstellte.Ich hatte einen sorglosen Fehler in einem meiner Signale auf Entry:

In myapp.__init__:

post_init.connect(entry_initialized, sender=Entry) 

In 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) 

Die richtige Version von meinem Code wäre:

 #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() 
Verwandte Themen