The function slices a queryset into smaller querysets containing chunk_size objects and then yield them. It is used to avoid memory error when processing huge queryset, and also database error due to that the database pulls whole table at once. Concurrent database modification wouldn't make some entries repeated or skipped in this process.
This manager is based on the economical method of randomization. It usable in related models. For support this behavior required to be defined as default manger.
Because select_related() only works on ForeignKeys that are not null or blank, when you are customizing the admin, even if you set "list_select_related=True" you can still end up with way too many querys in the Admin changelist. By adding this code to your model you can decrease the queries dramatically. I found I needed this when I was working with Django apps with a lot of legacy data and I couldn't set the ForeignKey null=False.
This is a Python 3 re-write for https://djangosnippets.org/snippets/2117/
I want to create Mixins for QuerySet objects that will by default filter out certain records (e.g. filter out "deleted" records, or filter out "unapproved" records, etc). I'd like those to be separate independent mixins. So in each of those, I override all() to filter out deleted or unapproved, etc. But, I also want to offer a method in the queryset to remove those filters or remove some part of those filters. That's where this code comes in. After some examination of how QuerySets work, this seemed like the simplest method for "undoing" some filter in a queryset
SELECT FOR UPDATE, which does row-level locking in the database, was added by Django only in version 1.4. This snippet emulates that feature in older versions of Django. Tested in Django 1.2, but should work in newer versions as well. select_related is removed because it causes errors when used with RawQuerySet.
This snippet is greatly inspired by [@jlorich](http://djangosnippets.org/users/jlorich/)'s useful [#2436](http://djangosnippets.org/snippets/2436/). The main difference is that I wanted to choose the names of my URL params instead of being forced into naming them "value1", "value2", etc. When reversing the URL you have to remember that the kwargs aren't friendly. By using the same names in the `filters` list, you don't have to change the way your otherwise write the URL pattern. Also it's clear throughout how you'll be filtering the QuerySet. The other change I made was "erroring early". This avoids running the QuerySet all over again inside `object_detail()` just to have it raise an exception we could have caught the first time.
This snippet shows how to add additional parameters to the queryset of a ModelChoiceField, enabling you to for instance filter the query.
This snippet for django-1.2 allows you to use bitwise operators without using QuerySet.extra() from django.db.models import * from somewhere import FQ class BitWise(Model): type = CharField(max_length=8) value = IntegerField() def __unicode__(self): return '%s - %d' % (self.type, self.value) >>> BitWise.objects.create(type='django', value=1) <BitWise: django - 1> >>> BitWise.objects.create(type='osso', value=3) <BitWise: osso - 3> >>> BitWise.objects.create(type='osso', value=7) <BitWise: osso - 7> >>> BitWise.objects.filter(FQ(F('value') & 1, 'gt', 0)) [<BitWise: django - 1>, <BitWise: osso - 3>, <BitWise: osso - 7>] >>> BitWise.objects.filter(FQ(F('value') & 2, 'gt', 0)) [<BitWise: osso - 3>, <BitWise: osso - 7>] >>> BitWise.objects.filter(FQ(F('value') & 1, 'gt', 0) & Q(type='django')) [<BitWise: django - 1>]