Perhaps you don't want to drop a table, but you also want to do something faster than Model.objects.all().delete() but without resorting to raw SQL. This function, clear_tables, will call the sql_flush operation on a list of tables.
This snippet is for resolve the Django-PyAMF unicode problems, through the django force_unicode function called recursively, with a tuple of different charsets.
This is a slight improvment of a previous snippet of mine:
http://www.djangosnippets.org/snippets/1776/
It is an interactive shell script that greps and deletes sqlite tables
USAGE:
./pdrop.sh myquery mydbfile
Allows the whole widget to be required but still have optional fields in it.
For instance we have a NameField, which takes a firstname and lastname and optionally a middlename.
With this we can just have 1 widget.
Allows you to hide the filters in the pages of lists of admin.
Very useful when filters hide one or more columns.
Add this code after the block "extrastyle"
Returns a list of date objects for a given number of past days, including today. Useful for summaries of recent history.
Inspired by [Template range filter](http://www.djangosnippets.org/snippets/1357/)
This is a custom template tag that clears the cache that was created with the **cache** tag.
{% load clearcache %}
{% clearcache [fragment_name] [var1] [var2] .. %}
Create **app/templatetags** folder with **__init__.py** and copy code into **clearcache.py** file.
polls/
templatetags/
__init__.py
clearcache.py
Based on django.templatetags.cache. See Django docs on [custom template tags](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/)
There are times when you want to hook into the Variable class of django.template to get extra debugging, or even to change its behavior. The code shown is working code that does just that. You can monkeypatch template variable resolution by calling patch_resolver(). I recommend using it for automated tests at first.
My particular version of _resolve_lookup does two things--it provides some simple tracing, and it also simplifies variable resolution. In particular, I do not allow index lookups on lists, since we never use that feature in our codebase, and I do not silently catch so many exceptions as the original version, since we want to err on the side of failure for tests. (If you want to do monkeypatching in production, you obviously want to be confident in your tests and have good error catching.)
As far as tracing is concerned, right now I am doing very basic "print" statements, but once you have these hooks in place, you can do more exotic things like warn when the same object is being dereferenced too many times, or even build up a graph of object interrelationships. (I leave that as an exercise to the reader.)
If you want to see what the core _resolve_lookup method looks like, you can find it in django/templates/__init__.py in your installation, or also here (scroll down to line 701 or so):
[source](http://code.djangoproject.com/browser/django/trunk/django/template/__init__.py)
This is a basic model view for exporting data from models. It is designed so that you can provide the GET variables used for searching/filtering within listdisplay pages in the admin, and the code will filter the same way.
It allows the output of model data in various formats using serializers or templates.
A simple replacement for Django's default GZipMiddleware which breaks when trying to serve files or pass any kind of iterators to the HttpResponse object.
Simply replace GZipMiddleware with the provided middleware and set response.dontgzip = True when returning the response, and it will then be ignored by the middleware.
This is replace for django.contrib.redirects.RedirectFallbackMiddleware which redirects exact matches as well as startswith matches for the redirect.old_path
I had a problem with my urls, because are dynamically generic, so I can't create one redirect entry on the database for each possible url. So I made django redirects to search any redirect with the exact match or any database entry being the head of my url, for example:
I have django redirects which redirects /calendars/3434/ --> / . But when I have a 404 on /calendars/3434/c/2009/10/23/ now it redirects properly. So my redirects now acts as /calendars/3434/*
You're looking at the most-bookmarked snippets on the site; if you'd like to help useful snippets show up here, sign up for an account and you'll get your own bookmarks list.