SQL Log Middleware w/query count & exec time
This middleware will add a log of the SQL queries executed at the bottom of every page. It also includes a query count and total and per-query execution times.
- sql
- middleware
- log
This middleware will add a log of the SQL queries executed at the bottom of every page. It also includes a query count and total and per-query execution times.
Adds a hidden footer to the bottom of every text/html page containing a list of SQL queries executed and templates that were loaded (including their full filesystem path to help debug complex template loading scenarios). To use, drop in to a file called 'debug_middleware.py' on your Python path and add 'debug_middleware.DebugFooter' to your MIDDLEWARE_CLASSES setting.
http://paltman.com/2008/04/11/keeping-contenttypes-and-permissions-updated-without-syncdb/
A helper.
Just put it in your python path and add it into MIDDLEWARE_CLASSES. I know that there are a couple of snippets on this site that do something similar to this, but none of them quite suited me. I wanted something that would indent and space the SQL so that I could differentiate it from the other output from the development server. Also, I wanted something that would output total query execution time, which my solution does. I just hope that it's useful for someone else, too! UPDATE: Now this should no longer get upset when running it on windows.
A helper utility, does what name says.
before this works, you'll need to satisfy all the criteria for getting debug information in your template context: Have 'django.core.context_processors.debug' in your TEMPLATE_CONTEXT_PROCESSORS setting (it was there in the default settings, last time I checked). Have your current IP in your INTERNAL_IPS setting. Use RequestContext when rendering the current template (if you're using a generic view, you're already using RequestContext). [Manuale Django](http://www.darioagliottone.it/django-guida/)
Add this code to the end of the `<body>` of your main template and it will print out all your SQL queries with timings in the Firebug console. This uses the "django.core.context_processors.debug" template context processor, which requires that DEBUG=True and that your IP address is listed in INTERNAL_IPS.
A management.py loading customized SQL feeding it raw to the database backend. Just put it as `management.py` in your app and put whatever SQL you want run after syncdb in `app/sql/custom.backend_driver.sql`. If the `backend_driver` is skipped the SQL will be loaded no matter database backend. Since it is run after syncdb it will also be run for test.
[See blog post](http://paltman.com/2008/04/11/keeping-contenttypes-and-permissions-updated-without-syncdb/) You can put this script in the root of your project and run after deploying updates in your production environment.
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.
These snippets together give you the ability to view all Django SQL queries executed across all incoming requests by visiting a particular URL (`/profiling` in the example). This is useful when developing with the Django test server. This is useful if most of the incoming requests are AJAX requests, because in such cases the debug toolbar will not be able to show which queries got executed. The `SqlProfilingMiddleware` class is the key one. At the end of every incoming request it appends the executed SQL queries to a static class member list. Any information request profiling information can be added in this way. The snippet does not add any security around viewing such information. This was done just to keep the code simple. But when implementing this you will definitely want to restrict access to this URL to only people allowed to view such information.
The script that can be used to profile any Django-powered web-site and find how many SQL-queries are used per page, how heavy html-pages are, etc. To use the the script it's enough to put django-profile.py somewhere in PYTHONPATH and call it from the directory that holds projects' settings.py. For more info and examples please see: [www.mysoftparade.com/blog/django-profile-sql-performance/](http://www.mysoftparade.com/blog/django-profile-sql-performance/)
I know you're thinking, *what the heck could that title mean?* I often find myself wanting to filter and order by the result of a COUNT(*) of a query using a method similar to the [entry_count example](http://www.djangoproject.com/documentation/db-api/#extra-select-none-where-none-params-none-tables-none). Writing this many times is tedious and hardcoding the table and column names made me cringe, I also wanted the counts to result from more complex queries. This is a method you can add to your custom Manager to do this easily. It's not an ideal syntax, but it's good for the amount of code required. Example: suppose we have some articles we want to filter and order by comments and visit logs to show the most popular... class ArticleManager(models.Manager): count_related = _count_related class Article(models.Model): pub_date = models.DateTimeField(auto_now_add=True) objects = ArticleManager() class Comment(models.Model): article = models.ForeignKey(Article) is_spam = models.BooleanField(default=False) class Visit(models.Model): article = models.ForeignKey(Article) referrer = models.URLField(verify_exists=False) search_query = models.CharField(maxlength=200) Notice how the ArticleManager is given the `count_related` method. Now you can find the most popular like so... Order by non-spam comments: Article.objects.count_related(Comment.objects.filter( is_spam=False)).order_by('-comment__count') Order by incoming non-search-engine links: Article.objects.count_related(Visit.objects.filter( referrer__isnull=False, search_query__isnull=True), 'links').order_by('-links') Order by total visits: Article.objects.count_related(Visit).order_by('-visit__count') Note: Doesn't work if `query` contains joins or for many-to-many relationships, but those could be made to work identically if there's demand.
Drops all tables in MySQL table (either managed by Django or not). Useful when resetting the database with no CREATE DATABASE privileges. MySQL-only.