django database snippet
..
- log
- database
..
Place the code any admin.py file in your registered apps
This is a simple logging [filter](https://docs.djangoproject.com/en/1.5/topics/logging/#topic-logging-parts-filters) to ensure that user-entered passwords aren't recorded in the log or emailed to admins as part of the request data if an error occurs during registration/login.
This is an improvement of [joshua](http://djangosnippets.org/users/joshua/)'s [SQL Log Middleware](http://djangosnippets.org/snippets/61/). If you have more than one database connection, then all queries are logged, grouped by connection. If a connection has no queries, then it's not shown.
Due to compliance requirements in the financials industry we needed to log every request a user made to our system, the action taken (view function) and response from the server. I found a lot of other logging solution bit most revolved around debugging and DB query logging. I needed to be able to tell what a user did while being logged in as much detail as I could with out tracking the mouse pointer position on screen. So I created this (, *my first* ,) middleware. Its very simple really. keeping track of a request, view_func and response object in a single model called Record (models.py file included in the code). The fields I used are optimized to what I intend to show in the UI I am planning for this model. Depending on how you use the doc string of your views they can be tapped to explain to the user what each request/func/responce group in a session is meant to do. There were a few gotcha's: 1. I only care about authenticated requests. So I added the 'quest.user.is_authenticated()' test. 2. I did not care about the favicon request so I skipped them. 2. The actual login request is not authenticated while the response is. This caused the process_response/view to look for a record that is not there. So I added the 'except ObjectDoesNotExist' to skip this case. I added one bell: Logging a full HTML reply is wasteful and mostly useless. I added two values in the setting files. LOGALL_LOG_HTML_RESPONSE to toggle if we want to log them or not. And LOGALL_HTML_START to describe what a full HTML starts with. Personally I use the first few characters of my base.html template that all the rest of my templates expend. I simplified the code to the left for readability.
This is a piece of middleware that reports the logged-in user back to Apache. This should cause the logged-in user to be present in the apache access log. Put it in `settings.MIDDLEWARE_CLASSES` after `AuthenticationMiddleware`. This has been tested with mod_python but does [not work with wsgi](http://groups.google.com/group/modwsgi/browse_thread/thread/8785a99d4ba7ee99).
When running the Django development server, this middleware causes all executed SQL queries to get printed out to the console. This is based on [Snippet 161](http://www.djangosnippets.org/snippets/161/). The big difference is that 161 logs by adding stuff to your response text, which isn't very convenient IMO.
The django_admin_log only logs changes, not simple requests. Sometimes it can be useful to log when a user of your admin interface is checking out important data, for instance if you are making a system with personal sensitive data, that needs to comply with government / company policies. This will log such hits to the django_admin_log by overriding the change_view method in ModelAdmin. So you must override this method in all classes you want to have logged.
We had some fun today on the #django IRC channel searching and counting through past logs for people saying "thanks" to [a known very helpful person](http://djangopeople.net/magus/). Here's a unix shell script for checking your own score if you're using Pidgin and have logging turned on. Replace ".purple" with ".gaim" in the script if you're using Gaim (an older version of Pidgin).
This is another example use of the [exception middleware](http://www.djangosnippets.org/snippets/638/). It shows how to log exceptions to a file. Someone wanted to do this to avoid DOS-ing the email server in case of a silly error. (untested.)
Yet another SQL logger, this time with color and tresholds. By default it will only print a summary line (total time, query count) unless one of the tresholds (total time, query count, individual query time) was exceeded. You may use LOG_COLORSQL_VERBOSE = True to get the raw SQL for all requests regardless of any configured tresholds. In either case the middleware will highlight problematic areas in yellow or red. If you don't like the colors you can either set your tresholds to really high values, edit the code, or use a different middleware. :-)
The solution is based on [dballanc's snippet](http://www.djangosnippets.org/snippets/420/). Can easily be combined with any of the [SQL tracing solutions](http://www.djangosnippets.org/tags/debug/). You might want to run a separate logging server and redirect your logs there. Please refer to the [logging reference manual](http://docs.python.org/lib/module-logging.html).
This is based on [Snippet 161](/snippets/161/) It marks duplicated SQL queries. To avoid duplicates read: [Caching and Queryset](http://www.djangoproject.com/documentation/db-api/#caching-and-querysets) Sept. 07: Updated for current trunk: 'response' behaves like 'response.header' 22. October '07: Log into directory.
Use this script to import the Maxmind GeoIP lite CSV datasets into your database. This takes at least 200MB of RAM; the resulting database will be ~400MB. Stick in the same directory as the [models](http://www.djangosnippets.org/snippets/327/). Make sure to set `DEBUG=False` to prevent running out of memory during import.
This provides GeoDjango models for the maxmind GeoIP Lite data products. Use the corresponding [CSV import script](http://www.djangosnippets.org/snippets/328/) for data import. Requires: [GeoDjango](http://code.djangoproject.com/wiki/GeoDjango) and the [BigIntegerField patch](http://code.djangoproject.com/attachment/ticket/399/django-bigint-20070712.patch) by Peter Nixon.
18 snippets posted so far.