Databases
StackOverflow2013
Postsdbo
POManager Returns Model Objects Once Per Request (Manager Drops Objects After Returning Them Once)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POManager Returns Model Objects Once Per Request (Manager Drops Objects After Returning Them Once)
    primarykey
    data
    text
    <p>The behavior was unrelated to the problem as presented immediately below. See the bottom of the post for an explanation. thanks.</p> <hr> <p>Hello,</p> <p>I am currently experiencing the behavior that the default Manager for a particular Model returns the objects for this Model only once per request or per shell session. Below is a PDB transcript from stopping in a view (but the behavior occurs without PDB, too):</p> <pre><code>#Nothing up my sleeves (using the default Manager): (Pdb) p Entry.objects &lt;django.db.models.manager.Manager object at 0x18523b0&gt; #Now you see them... (Pdb) Entry.objects.all() [&lt;Entry: Entry 1&gt;, &lt;Entry: Entry 2&gt;, &lt;Entry: Entry 3&gt;, &lt;Entry: Entry 4] #Now you don't! (Pdb) Entry.objects.all() [] </code></pre> <p>Anytime I retrieve an object, that object no longer appears in later QuerySets.</p> <pre><code>#(New Request from above) #If I only request one object then it is the one that disappears (Pdb) Entry.objects.all()[0] [&lt;Entry: Entry 1&gt;] #Here Entry 1 is missing (Pdb) Entry.objects.all() [&lt;Entry: Entry 2&gt;, &lt;Entry: Entry 3&gt;, &lt;Entry: Entry 4] #And now they're all gone. (Pdb) Entry.objects.all() [] </code></pre> <p>This behavior is only for one of my models; the other models seems to query correctly. I don't think that it has anything to do with my Model's definition, which is basicaly:</p> <pre><code>class Entry(models.Model): user = models.ForeignKey(User, related_name='entries') blog = models.ForeignKey(Blog, related_name='entries') positive = models.BooleanField() </code></pre> <p>I apologize that my description is a little vague; I'm confused about how this behavior could arise and not sure where to poke around next.</p> <p>The SQL generated by the Manager for the QuerySet is the same (and apparently correct) each time:</p> <pre><code>(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() [&lt;Entry: Entry 1&gt;, &lt;Entry: Entry 2&gt;, &lt;Entry: Entry 3&gt;, &lt;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() [] </code></pre> <p>I'm using Django 1.0.2, Python 2.6.1, and the SQLite that came packaged with Python 2.6.1 on a Mac OS 10.5 machine.</p> <p>In response to one of the comments I tried renaming the <code>related_name</code> parameters to <code>entries1</code> and <code>entries2</code> to avoid a possible conflict but this did not change the behavior.</p> <hr> <p>SOLVED (I think)</p> <p>Sorry all, the problem was actually unrelated to the problem as I presented it. I had a careless bug in one of my signals on Entry:</p> <p>In <code>myapp.__init__</code>:</p> <pre><code>post_init.connect(entry_initialized, sender=Entry) </code></pre> <p>In <code>myapp.signals</code>:</p> <pre><code>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) </code></pre> <p>The correct version of my code would be:</p> <pre><code> #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() </code></pre>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCarl G
    1. USCarl G
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POManager Returns Model Objects Once Per Request (Manager Drops Objects After Returning Them Once)
      1. USAlexandr
      1. VTFavorite
    1. COYes, that's a head scratcher :) Is the model manager the default? If it's a custom manager you'll need to post the source to the manager somewhere. Also, it might help to look at the query being generated, i.e., qs = Entry.objects.all() ; print qs.sql
      singulars
      1. POManager Returns Model Objects Once Per Request (Manager Drops Objects After Returning Them Once)
      1. USVan Gale
    2. COStrange. Nothing wrong with the model. Even i would like to have a look at manager code if its not the default one. Please paste it.
      singulars
      1. POManager Returns Model Objects Once Per Request (Manager Drops Objects After Returning Them Once)
      1. USsimplyharsh
    3. COmaybe same related_name='entries' is affecting somehow, they should be defferent as far as i know
      singulars
      1. POManager Returns Model Objects Once Per Request (Manager Drops Objects After Returning Them Once)
      1. USuser20955
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload