Login

Tag "queryset"

39 snippets

Snippet List

Generic model filter from request GET data

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

  • filter
  • forms
  • queryset
Read More

Lightweight querysets

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.

  • queryset
  • defer
  • lightweight
Read More

SelectRelatedManager

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.

  • admin
  • manager
  • select
  • queryset
Read More

Django model objects and querysets dehydration/hydration

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

  • models
  • orm
  • queryset
  • hydrate
  • dehydrate
Read More

get_queryset_or_404

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.

  • shortcut
  • template
  • queryset
  • get_queryset_or_404
  • get_list_or_404
Read More

Easier chainability with custom QuerySets

Django allows you to specify your own ModelManager with custom methods. However, these methods are chainable. That is, if you have a method on your PersonManager caled men(), you can't do this: Person.objects.filter(birth_date__year=1978).men() Normally, this isn't a problem, however your app may be written to take advantage of the chainability of querysets. For example, you may have an API method which may return a filtered queryset. You would want to call with_counts() on an already filtered queryset. In order to overcome this, we want to override django's QuerySet class, and then make the Manager use this custom class. The only downside is that your functions will not be implemented on the manager itself, so you'd have to call `Person.objects.all().men()` instead of `Person.objects.men()`. To get around this you must also implement the methods on the Manager, which in turn call the custom QuerySet method.

  • model
  • manager
  • queryset
Read More

ParentModel and ChildManager for Model Inheritance

This is the approach I've taken to access instances of child models from their parent. Functionally it's very similar to snippets [1031](http://www.djangosnippets.org/snippets/1031/) and [1034](http://www.djangosnippets.org/snippets/1034/), but without the use of `django.contrib.contenttypes`. Usage: class Post(ParentModel): title = models.CharField(max_length=50) objects = models.Manager() children = ChildManager() def __unicode__(self): return self.title def get_parent_model(self): return Post class Article(Post): text = models.TextField() class Photo(Post): image = models.ImageField(upload_to='photos/') class Link(Post): url = models.URLField() In this case, the `Post.children` manager will return a queryset containing instances of the appropriate child model, rather than instances of `Post`. >>> Post.objects.all() [<Post: Django>, <Post: Make a Tumblelog>, <Post: Self Portrait>] >>> Post.children.all() [<Link: Django>, <Article: Make a Tumblelog>, <Photo: Self Portrait>]

  • model
  • manager
  • queryset
  • inheritance
Read More

SELECT FOR UPDATE in Django < 1.4

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.

  • queryset
Read More

Querying datetime aware objects in your local timezone

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

  • datetime
  • timezone
  • queryset
  • utc
  • local
  • datetimefield
Read More

User manager

If you have a model with foreign key to User, you can use this manager to show (i.e. in admin interface) only objects, that are related to currently logged-in user. Superuser sees all objects, not only his. Requires: [ThreadlocalsMiddleware](http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser)

  • filter
  • foreignkey
  • user
  • manager
  • queryset
  • owner
  • users
  • user-foreign-key
Read More

Generic object_detail view with multiple named URL filters

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.

  • filter
  • urlconf
  • generic-views
  • queryset
  • urlpatterns
Read More

Chainable custom query manager for randomize.

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.

  • queryset
  • related-models
  • randomize
  • custom-manager
Read More