""" 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 """
Use this to display a split of page execution time between python and the db in your base template when debugging. I originally got the base of this code from another snippet, but I can't find it anymore and want to share with new folks because I find this handy.
A module to serializers/deserializes Django Q (query) object
qurl is a tag to append, remove or replace query string parameters from an url (preserve order)
Some template tags/filter for working with query strings in templates. Examples: {% load qstring %} {% qstring %} # Prints current request's query string {% qstring as current_qstring %} # Same but goes to context {{ current_qstring|qstring_del:"key1" }} # Deletes all key1 values {{ current_qstring|qstring_del:"key1&key2" }} # Deletes all key1 and key2values {{ current_qstring|qstring_set:"key1=1&key2=2" }} # Deletes all old key1 and key2 values and adds the new values.
Modify a query string on a url. The comments in the code should explain sufficiently. String_to_dict, and string_to_list are also useful for templatetags that require variable arguments.
A `models.Manager` subclass that helps to remove some of the boilerplate involved in creating managers from certain queries. Usually, a manager would be created by doing this: class MyManager(models.Manager): def get_query_set(self): return super(MyManager, self).get_query_set().filter(query=blah) Other managers may return other query sets, but this is especially useful as one may define queries on a table which would be used a lot. Since the only part that ever changes is the `query=blah` set of keyword arguments, I decided to abstract that into a class which, besides taking the repetition out of manager definition, allows them to be and'd and or'd in a manner similar to the `Q` objects used for complex database queries. `CustomQueryManager` instances may be defined in one of two ways. The first, more laborious but reusable manner, is to subclass it, like so: class MyManager(CustomQueryManager): query = Q(some=query) Then, `MyManager` is instantiated with no arguments on a model, like normal managers. This allows a query to be reused without extra typing and copying, and keeps code DRY. Another way to do this is to pass a `Q` object to the `__init__` method of the `CustomQueryManager` class itself, on the model. This would be done like so: class MyModel(models.Model): field1 = models.CharField(maxlength=100) field2 = models.PositiveIntegerField() my_mgr = CustomQueryManager(Q(field1='Hello, World')) This should mainly be used when a query is only used once, on a particular model. Either way, the definition of `__and__` and `__or__` methods on the `CustomQueryManager` class allow the use of the `&` and `|` operators on instances of the manager and on queries. For example: class Booking(models.Model): start_date = models.DateField() end_date = models.DateField() public = models.BooleanField() confirmed = models.BooleanField() public_bookings = CustomQueryManager(Q(public=True)) private_bookings = public_bookings.not_() confirmed_bookings = CustomQueryManager(Q(confirmed=True)) public_confirmed = public_bookings & confirmed_bookings public_unconfirmed = public_bookings & confirmed_bookings.not_() public_or_confirmed = public_bookings | confirmed_bookings public_past = public_bookings & Q(end_date__lt=models.LazyDate()) public_present = public_bookings & Q(start_date__lte=models.LazyDate(), end_date__gte=models.LazyDate()) public_future = public_bookings & Q(start_date__gt=models.LazyDate()) As you can see, `CustomQueryManager` instances can be manipulated much like `Q` objects, including combination, via `&` (and) and `|` (or), with other managers (currently only other `CustomQueryManager` instances) and even `Q` objects. This makes it easy to define a set of prepared queries on the set of data represented by a model, and removes a lot of the boilerplate of usual manager definition.
This is an improvement on [snippet 1079](http://www.djangosnippets.org/snippets/1079/). Please read its description and [this blog post](http://zerokspot.com/weblog/2008/08/13/genericforeignkeys-with-less-queries/) for any information. This is a manager for handling generic foreign key. Generic foreign objects of the same type are fetched together in order to reduce the number of SQL queries. To use, just assign an instance of GFKManager as the objects attribute of a model that has generic foreign keys. Then: `MyModelWithGFKs.objects.filter(...).fetch_generic_relations()` The generic related items will be bulk-fetched to minimize the number of queries. **Improvement:** Problem I had with previous version from snippet 1079 : if two or more items shares the same generic foreign object, then only the first one is cached. Next ones generates new unwanted SQL queries. I solved this problem by putting all the needed foreign objects in a temporary data_map dictionary. Then, the objects are distributed to every items, so that if two items shares the same foreign object, it will only be fetched once.
**Attention: this snippet depends on jQuery library to works** The Admin templates hierarchy does not allow you change the submit line (that buttons bar in the footer of the change view of a model class). This code shows how to resolve this, using a simple javascript trick. You can read the code and implement using your favorite javascript library (instead of jQuery) or pure JavaScript. This example regards to User Profile, a common used model class that adds custom fields to a user in the authentication system. To use this, you must put this template code in a file with the following name: templates/admin/auth/user/change_form.html
QLeftOuterJoin object allows you to create 'LEFT OUTER JOIN' sql query. It is very usefull if you have to define ForeignKey to 'null=True' (select_related will not work with null=True). You are allowed to use QLeftOuterJoin like Q object. Example: `QLeftOuterJoin('thread_last_post', Post, 'pk', Thread, 'last_post')` It will generates SQL like: LEFT OUTER JOIN appname_post AS thread_last_post ON thread_last_post.id = appname_thread.last_post_id Table could be model or string.
This hack replaces all INNER JOINs inside to the LEFT OUTER JOINs (see http://code.djangoproject.com/ticket/3592 for explanation). Use: QLeftOuterJoins(Q(...) | Q(...) & (Q(...) | ....)).
This is an improvement on [snippet 984](http://www.djangosnippets.org/snippets/984/). Read it's description and [this blog post](http://zerokspot.com/weblog/2008/08/13/genericforeignkeys-with-less-queries/) for good explanations of the problem this solves. Unlike snippet 984, this version is able to handle multiple generic foreign keys, generic foreign keys with nonstandard ct_field and fk_field names, and avoids unnecessary lookups to the ContentType table. To use, just assign an instance of GFKManager as the objects attribute of a model that has generic foreign keys. Then: MyModelWithGFKs.objects.filter(...).fetch_generic_relations() The generic related items will be bulk-fetched to minimize the number of queries.
superSearch is intended to make it easier to make complex OR queries, thusly hitting the database less. EXAMPLE: Searching for a user named 'Eric Neuman' would be difficult because first_name and last_name are separate fields. However, with superSearch, it's a breeze. query = ['Eric Neuman'] f = ['first_name','last_name'] s = query.split(' ') m = ['icontains'] results = superSearch(User, f, m,s)
This class emulates query lookups to behave as numeric operators. Inspired by SQLAlchemy. User.objects.filter( X('username') == 'diverman' ) User.objects.filter( X('username') != 'diverman' ) User.objects.filter( X('pk') > 10 ) User.objects.filter( X('pk') >= 10 ) User.objects.filter( X('pk') < 10 ) User.objects.filter( X('pk') <= 10 ) User.objects.filter( X('username') % 'iverma' ) User.objects.filter( X('username') << 'diver' ) User.objects.filter( X('username') >> 'man' ) User.objects.filter( X('pk') | (1, 2, 3) )
Q() value in Django is identity for & operation: Q() & foo & bar & ... == foo & bar & ... QEmpty() is complimentary identity for | operation: QEmpty() | foo | bar | ... == foo | bar | ... QEmpty() itself returns empty queryset. Handy for complex query generation.