tags:

views:

283

answers:

3

I have a super simple django model here:

class Notification(models.Model):
    message = models.TextField()
    user = models.ForeignKey(User)
    timestamp = models.DateTimeField(default=datetime.datetime.now)

Using ajax, I check for new messages every minute. I only show the five most recent notifications to the user at any time. What I'm trying to avoid, is the following scenario.

User logs in and has no notifications. While the user's window is up, he receives 10 new messages. Since I'm only showing him five, no big deal. The problem happens when the user starts to delete his notifications. If he deletes the five that are displayed, the five older ones will be displayed on the next ajax call or refresh.

I'd like to have my model's save method delete everything but the 5 most recent objects whenever a new one is saved. Unfortunately, you can't use [5:] to do this. Help?

EDIT

I tried this which didn't work as expected (in the model's save method):

    notes = Notification.objects.filter(user=self.user)[:4]
    Notification.objects.exclude(pk__in=notes).delete()

i couldn't find a pattern in strange behavior, but after a while of testing, it would only delete the most recent one when a new one was created. i have NO idea why this would be. the ordering is taken care of in the model's Meta class (by timestamp descending). thanks for the help, but my way seems to be the only one that works consistently.

A: 

You can use this:

Notification.objects.order_by(-created_at)[5:].delete()
kibitzer
NO YOU CAN'T. I put that in my question for a reason. AssertionError at /notifyemployee/mailbox/thread/206/Cannot use 'limit' or 'offset' with delete.
Brandon H
SO is flawed, because now that three people upvoted your incorrect answer, this is no longer going to show up in unanswered.
Brandon H
+1  A: 

Use an inner query to get the set of items you want to keep and then filter on them.

objects_to_keep = Notification.objects.filter(user=user).order_by('-created_at')[:5]
Notification.objects.exclude(pk__in=objects_to_keep).delete()

Double check this before you use it. I have found that simpler inner queries do not always behave as expected. The strange behavior I have experienced has been limited to querysets that are just an order_by and a slice. Since you will have to filter on user, you should be fine.

istruble
i tried a method similar to this and it was quirky. when it got to a certain point it deleted all the objects with the user. i believe it has something to do with how slicing works with lazy querysets.
Brandon H
Add the code that you tried. I would appreciate more data points for the quirky behavior. For me, the order_by seemed to be stripped off the inner query if there was no filter(). Did you experience strange behavior with an Model.objects.filter(...).orber_by(...)[:5] inner query? Oh, and you might find <QuerySet>.query.as_sql() helpful.
istruble
i've edited my question with the code i tried. i didn't have the code which deleted all the objects, but i tried my code above (even more similar to yours), and that didn't work as i would have expected.
Brandon H
I like to be very explicit on things when trying to track down a problem. You might want to be explicit and add and order_by('-created_at') to your inner query. Also, you can also try looking at the raw sql with .query.as_sql(). `.delete()` does not have a .query property so remove it and add .query.as_sql() to see what is going on. Oh, probably easiest to do this in ./manage.py shell.
istruble
Emil Stenström
+1  A: 

this is how i ended up doing this.

    notes = Notification.objects.filter(user=self.user)
    for note in notes[4:]:
        note.delete()

because i'm doing this in the save method, the only way the loop would ever have to run more than once would be if the user got multiple notifications at once. i'm not worried about that happening (while it may happen it's not likely to be enough to cause a problem).

Brandon H
This is perfectly valid. And you are already aware of the fact that you will get a sql operation for each of those deletes inside the for loop. Thanks for the update.
istruble
Breaking out the above few lines on a method and adding a commit_on_success decorator around it makes sure it stays fast even though there's many queries to be made.
Emil Stenström