Have you ever felt the need to run multiple Django projects on the same memcached server? How about other cache backends? To scope the cache keys, you simply need to prefix. However, since a lot of Django's internals rely on `django.core.cache.cache`, you cannot easily replace it everywhere.
This will automatically upgrade the `django.core.cache.cache` object if `settings.CACHE_PREFIX` is set to a string and the Middleware contains `ScopeCacheMiddleware`.
A thread discussing the merging of this functionality into Django is available on [the dev mailing list](http://groups.google.com/group/django-developers/browse_thread/thread/d45edaafec56da2a).
However, (as of now) nowhere in the thread does anyone mention the reason why this sort of treatment is needed: Many of Django's internal caching helpers use `django.core.cache.cache`, and will then conflict if multiple sites run on the same cache stores.
Example Usage:
>>> from django.conf import settings
>>> from django.core.cache import cache
>>> from scoped_caching import prefix_cache_object
>>> settings.CACHE_PREFIX
'FOO_'
# Do this once a process (e.g. on import or Middleware)
>>> prefix_cache_object(settings.CACHE_PREFIX, cache)
>>> cache.set("pi", 3.14159)
>>> cache.get("pi")
3.14159
>>> cache.get("pi", use_global_namespace=True)
>>> cache.get("FOO_pi", use_global_namespace=True)
3.14159
>>> cache.set("FOO_e", 2.71828, use_global_namespace=True)
>>> cache.get("e")
2.71828
To Install: Simply add `ScopeCacheMiddleware` as a middleware and define `settings.CACHE_PREFIX` and enjoy!
- middleware
- cache
- namespace
Based on [danjak's](http://www.djangosnippets.org/users/danjak/) [snippet](http://www.djangosnippets.org/snippets/99/) but updated to use ModelForms - so can easily handle generic CRUD operations.
A replacement create_update.py for use with ModelForm
create_object and update_project modified to handle newforms (including FileFields) with ModelForm - it also had delete_object as well for completeness.
In addition, it has some extras:
* extra_fields - this is a dict or callable that contains additional fields to be passed to the form, for example stuff that is in the session.
* on_success - callback called if form is valid and object created/updated, if this is not set the default behaviour is to send a redirect
* on_failure - callback called if form is invalid, the default is to redisplay the form.
Note that once newforms are finally done these functions are likely to be redundant, as generic views will be updated to use the newforms API, so use with caution!
- newforms
- forms
- generic-views
- modelform
Django supports the serializing model objects, but does not support the serializing Q object like that,
============================
q = Q(username__contains="findme")
model0.objects.filter(q)
serialize(q) # X
============================
so I wrote a little marshaller for Q, this is example,
============================
from django.contrib.auth import models as django_models
qs = django_query.Q(username__contains="spike") | django_query.Q(email__contains="spike")
_m = QMarshaller()
a = _m.dumps(qs) # a was serialized.
When call the similiar queries in page by page, you don't need to write additional code for creating same Q(s) for filtering models, just use the serialized Q as http querystring and in the next page unserialize and apply it. That is simple life.