Snippet List
This is a different take on polymorphic inheritance, inspired by SQLAlchemy's approach to the problem.
The common Django approach (e.g. snippets 1031 & 1034, [django_polymorphic](http://github.com/bconstantin/django_polymorphic)) is to use a foreign key to `ContentType` on the parent model and override `save()` to set the right content type automatically. That works fine but it might not always be possible or desirable, for example if there is another field that determines the "real type" of an instance.
In contrast this snippet (which is actually posted and maintained at [gist.github](http://gist.github.com/608595)) allows the user to explicitly specify the field that determines the real type of an instance. The basic idea and the terminology (`polymorphic_on` field, `polymorphic_identity` value) are taken from [SQLAlchemy](http://www.sqlalchemy.org/docs/orm/inheritance.html).
Some other features:
* It works for proxy child models too, with almost no overhead compared to non-polymorphic managers (since there's no need to hit another DB table as for multi-table inheritance).
* It does not override the default (or any other) model Manager. Regular (non-polymorphic) managers and querysets are still available if desired.
* It does not require extending a custom Model base class, using a custom metaclass, monkeypatching the models or any kind of magic.
Splitting the information about a user across two models (User and UserProfile) is not to everyone's liking. This snippet monkeypatches the User model so that users can access transparently their profile information while still storing the data in two tables under the hood. Thus it is similar to the inheritance approach (http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/) but has the benefit of (a) not requiring a custom authentication backend or middleware and (b) loading the profile instance lazily, so there's no extra overhead if the profile infromation is not accessed. Read the docstrings for more details.
Deploying relocatable Django sites isn't currently as trivial as it should be (see http://code.djangoproject.com/ticket/8906, http://groups.google.com/group/django-developers/tree/browse_frm/thread/fa3661888716f940/). This snippet relocates all url patterns (similarly to http://djangosnippets.org/snippets/2129/) as well as the absolute url settings of `settings.py`.
This allows deployment under a different mount point with a single Django setting, without having to repeat the mount point again as a SCRIPT_NAME parameter supplied by the web server.
- deployment
- mount point
- relocatable
Auto-incremented primary keys are the default in Django and they are supported natively in most databases but for anything more complex things are less trivial. DB sequences are not standard, may not be available and even if they are, they are typically limited to simple integer sequence generators. This snippet bypasses the problem by allowing arbitrary auto-generated keys in Python.
The implementation needs to determine whether an IntegrityError was raised because of a duplicate primary key. Unfortunately this information is not readily available, it can be found only by sniffing the DB-specific error code and string. The current version works for MySQL (5.1 at least); comments about how to determine this in other databases will be incorporated in the snippet.
- mysql
- sequence
- uuid
- auto decrement
- auto increment
- primary key
This snippet makes Django templates support `break` and `continue` in loops. It is actually more powerful than the respective Python statements as it allows breaking and continuing from an outer loop, not just the innermost.
`break` and `continue` are implemented as template filters, with the input value being the loop variable. For example, to break from the current `for` loop use `forloop|break`, and to continue from the next outer loop use `forloop.parentloop|continue`.
The implementation monkeypatches Django (specifically Nodelist and ForNode) and has been tested on v1.2 with Python 2.6.
- template
- loop
- break
- continue
There are several snippets that provide a basic caching decorator for functions and methods (e.g. #202, #1130, etc.). The `Cacheable` class in this snippet extends them by (*if you don't see an unordered list below, the Markdown on this site is still broken...*):
- Specifying how cache keys are determined in one of two general, flexible ways.
- Exposing a few extra methods for (re)setting and deleting the cached value transparently. Given these methods, cache key management should follow DRY: keys are specified once (and only once) at instantiation time, without having to be repeated at later interactions with the cache.
- Adding a variant for cacheable properties.
Unlike some other snippets, the way cache keys are generated must be explicitly specified by the client; there is no automagic key generation for arbitrary `func(*args, **kwds)` calls (but can be added if desired). The reason is that all usual serialization approaches (`func.__name__`/`func.__module__`, `repr`, `pickle`, etc.) are generally fragile, unsafe, inefficient or all of the above. Explicit is better than implicit in this case.
**autoprefixed** is a decorator for Form classes that simplifies prefix handling by storing it in a hidden field. Thus when the form is posted, the prefix can be extracted from the posted data instead of having to pass it explicitly when instantiating the form.
Django loads tests found in models.py and tests.py (if present) or actually a module or package named 'tests' under the app. Since tests can be a package, one can create a 'tests' directory, split the test cases across multiple files under 'tests' and import them from tests/__init__.py with:
# tests/__init__.py
from test_mod1 import *
from test_mod2 import *
...
from test_modN import *
For a small number of files that's not too bad but it gets old as more files are added, plus it is error prone (e.g. test cases shadowing others with the same name). The snippet above simplifies the test splitting without importing everything into the same namespace.
Typical usage:
# tests/__init__.py
from ... import get_suite
suite = lambda: get_suite(__name__)
Defining a custom template tag consists of three parts: a compiling function, a rendering `Node` subclass and a tag registration with `register.tag()`. The latter can be used as a (function) decorator on the compiling function, simplifying things into two parts.
A neat fact is that `register.tag()` can actually be used as a class decorator in Python 2.6+ to condense all steps into the `Node` subclass. The compiling function simply becomes the `__init__()`. Below are two variants of the 'current_time' tag example from the Django docs: the first passing an explicit tag name and the second using the class name instead.
- template-tags
- class-decorator
gsakkis has posted 13 snippets.