Sometimes we want to get a queryset or 404, for example, if we're passing our queryset to a subclassed generic view. This is identical to get_list_or_404 but returns a queryset.
This is a function to take a Q object and construct a function which returns a boolean. This lets you use the exact same filter syntax that Django's managers use and apply it inside list comprehensions, or to non-persistent objects, or to objects of different types with the same attribute names.
I have a model with a datetime field that I used as a timestamp. I’m in California’s timezone (“America/Los_Angeles”). The data is saved in UTC in MySQL (as confirmed by the ORM). I just want to do a query that looks like this: “give me all the information with day X’s timestamp” (24 hour period). But the timestamp is a datetime, not date. If you just do varname.date(), it’s still UTC’s date, not your local timezone’s date. Here’s what I did: 1. First construct the start and end time period covering the 24 hour period of that day you want 2. Make it an “aware” (not naive) datetime 3. Filter for the __range
You just use standart django query terms, for example: <form> <input class="field_text filter_from" type="text" name="cost__gte" placeholder="from" value="{% if request.GET.cost__gte %}{{ request.GET.cost__gte }}{% endif %}"> <input class="field_text filter_to" type="text" name="cost__lte" placeholder="to" value="{% if request.GET.cost__lte %}{{ request.GET.cost__lte }}{% endif %}"> </form> model: class Object(models.Model): cost = models.IntergerField() objects = ObjectManager()
Using Python mixins, you can chain methods on your queryset.
A zen study.
Suppose you have two models A and B. The models have lots of large text/json fields and other heavy data. Your view is showing some list of `B.select_related(A)`, however, it is using just few lightweight fields. You want to defer all heavyweight fields in order to offload your DB and limit its traffic, but it is a tedious error prone work, that smells a bit with over-optimization. Real example, you have Product and Category objects. Both have large description fields with lots of text data. However, these fields are only needed on product detail page or on category detail page. In other cases (eg. side menu, some product suggestion block etc) you just need few lightweight things. Solution: add `LightweightMixin` to your models manager and specify your `heavyweight_fields` and `always_related_models`. # all visible products with necessary relations prefetched and heavyweight # fields deferred. qs = Product.objects.lightweight() # custom queryset with default defers applied. description and ingredients fields will # be normally deferred, but in this case they are explicitly selected qs = Product.objects.filter(my_filter="that", makes="sense") qs = Product.objects.as_lightweight(qs, select=('description', 'ingredients')) The best way to work with this snippet is to add the mixin to all managers in order to use `lightweight()` and `public()` calls. The `as_public()` is intended for your visibility, `select_related()` and `batch_select()` queryset settings. When you need full blown object, use `public()` queryset. When you need a lightweight list of objects, use `lightweight()` queryset. When your application is completed, check the database querylog for frequent unnecessary large and ugly queries. Group all queries that were made by `lightweight()` querysets, make a list of unnecessary heavy fields and add them to manager's `heavyweight_fields`. If your `as_public()` uses `select_related()` joining heavy objects, then you can also specify `always_related_models` to defer some fields of these relations too. Why? Because database IO will become your major bottleneck someday, just because you fetch 2Mb of data in order to render some tiny menu. With proper caching this is not a major issue, but proper queries may be sign of proper coding.
Dehydrates objects that can be dictionaries, lists or tuples containing django model objects or django querysets. For each of those, it creates a smaller/dehydrated version of it for saving in cache or pickling. The reverse operation is also provided so dehydrated objects can also be re-hydrated. *Example:* >>> import pickle >>> users = list(User.objects.all()[:20]) >>> print users [<User: Indiana Jones>, <User: Bilbo Baggins>, ...] >>> pickled_users = pickle.dumps(users) >>> print len(pickled_users) 17546 >>> dehydrated_users = dehydrate(users) >>> pickled_dehydrated_users = pickle.dumps(dehydrated_users) >>> rehydrated_users = hydrate(pickle.loads(pickled_dehydrated_users)) >>> print rehydrated_users [<User: Indiana Jones>, <User: Bilbo Baggins>, ...] >>> print len(pickled_dehydrated_users) 1471
The popular [django-tagging](http://code.google.com/p/django-tagging/) app has, in its implementation and semantics, a highly usable and transparent elegance -- but then you have to call methods on a Tag instances' items collection. These classes let you inline the tag name in the chain of queryset filter methods instead. TO USE: ### models.py ... from tagging.fields import TagField from tagging.models import Tag as Tag class YourModel(models.Model): ... yourtags = TagField() objects = TaggedManager() ... ### and then elsewhere, something like-- ... ym = YourModel.objects.order_by("-modifydate")[0] anotherym = YourModel.objects.get(id=7) ## distinct from ym ym.yourtags = "tag1 tag2" anotherym.yourtags = "tag1 othertag" ym.save() anotherym.save() with_tag1 = YourModel.objects.tagged('tag1') with_tag2 = YourModel.objects.tagged('tag2').order_by('-modifydate') print ym in with_tag1 ## True print anotherym in with_tag1 ## True print ym in with_tag2 ## False ... since these are QuerySets, you can easily create unions (e.g. `with_tag1 | with_tag2` and othersuch) as you need and filter them to your hearts' content, without having to instantiate Tag all the time (which you can of course do as well).
We needed to override the default QuerySet delete function to deal with a client problem that we were facing Yes This is monkey-patching, and probably bad practice but if anyone needs to conditionally override the cascading delete that django does at the application level from a queryset, this is how to do it
Install [sqlparse](http://code.google.com/p/python-sqlparse/) with `easy_install sqlparse` and then you can easily debug the SQL like this: def view(request): data = MyModel.objects.filter(something__very=complex) print_sql(data) ... Inspired by [Simon Willison](http://simonwillison.net/2009/Apr/28/)
Example view code: lazy_field_options = { 'field_name_that_is_m2m': { 'queryset': YourRelatedModel.objects.filter(groups=request.user.groups.all()), }, 'field_name_that_is_fk': { 'queryset': YourOtherRelatedModel.objects.filter(slug=request_slug), }, } modelform = YourModelForm(jpic_field_options=lazy_field_options) # after the modelform has called for parent __init__, it will set # options for each field if possible.
My modified version of the [MultiQuerySet by mattdw](http://www.djangosnippets.org/snippets/1103/) (see the link for further information). My purpose for this was to enable me to combine multiple different types of querysets together, which could then be iterated on as one object (i.e. like a tumblelog).
This utility is useful when you want to safely retrieve a single object from the database without having to wrap get() in a try/except block every time. It also supports query optimization via select_related and prefetch_related, making it ideal for performance-conscious applications.
""" Takes arguments & constructs Qs for filter() We make sure we don't construct empty filters that would return too many results We return an empty dict if we have no filters so we can still return an empty response from the view """