Debugging in Django
For Django newcomers, it will be useful to learn about a very useful debugging tool - the debug-toolbar . He is so cool that he is called Firebug for Django . On large projects, you cannot do without it (or another debugger).
Debug-toolbar is a set of panels that appear on a page in debug mode.
The set of panels can be changed. Currently available 9 pieces. Here are some details:
Shows the version of Django. I usually turn off this panel, because I know the version without prompts, and there is so little space on the screen.
Application runtime and number of context switches.
Very harmful tab. If you keep these numbers always in front of your eyes, the project cannot be delivered on time - it will always seem that all operations are performed at least 10 times longer than they could.
Remember: "Premature optimization is the root of all evil."
Here you can see all the Django settings from the settings.py file of this application. I don’t know if this is of great use - you can always see the config in the file.
Theoretically, there should be headers of the HTTP request, which led to the display of the investigated page. But actually in this panel I see a list of server environment variables:
Not often needed, but good when such information is at hand.
Here you can see the cookies for this domain, Django session variables, as well as the variables passed in the GET / POST request. You can imagine it without a picture.
The template information panel with which the output occurs. Probably works well when using the native Django template engine. And for outsiders, only viewing contexts works:
Powerful thing. Shows all database queries, their execution time and full trace.
This allows you to identify a query that is problematic in performance and easily find it even in the most confusing application with template inheritance. It works for any template engine, it seems.
By the way, any query can be executed directly from the panel, and you can also ask for it Explain or even Profile (if the database supports).
The panel allows you to view write and read acts from the cache, information received, time spent and other cache statistics:
For example, in this picture you can see that there was an attempt to take the update_sites key from the cache, but it turned out to be empty (the cache was expired). Then there was a write to the cache of new data. I want to believe that in the Time column the correct order of numbers and dimension.
It's like console.log ('Hello'). Prints debugging messages from the logging Python module. To get the debug output, you need to connect the module and say something into it: It is a pity that different message levels are not highlighted.
Personally, I only connect debug_toolbar in debug mode: “INTERCEPT_REDIRECTS = False” disables redirect hooking. If you do not disconnect, then first there will be a redirect to the debug page, where it will be described in detail where we were redirected from and to. And the link will be given a click. EXCLUDE_URLS will theoretically someday disable the debugger for the specified directories. Left in order not to forget to try in a year. That would be to cut it down for the necessary subdomains ...
The product is a little damp. Its various minor details may not work or work incorrectly. I had to pick a template and js files for about 15 minutes to get the “Hide” button working. The script requires jquery and the cookies plugin (the cookie saves the state of the panel - closed / open). For some reason, the plugin was connected after the toolbar.js script crashed with an error.
For a long time I also miscalculated the formatting of time output in all panels: well, why should I see hundredths of a millisecond? But these are all little things that can be easily dealt with or simply ignored.
There can be difficulties when using some tricky middleware. I had to modify the file class, organizing work with subdomains within the same server.
There are opinions that this fork of this toolbar is slightly better. I still can’t say exactly about functionality, but the interface ...
For such a debugger interface, someone could sell the soul to the devil! Need to try.
Found a mistake - write to Habrapost.
Debug-toolbar is a set of panels that appear on a page in debug mode.
The set of panels can be changed. Currently available 9 pieces. Here are some details:
Version
Shows the version of Django. I usually turn off this panel, because I know the version without prompts, and there is so little space on the screen.
Timer
Application runtime and number of context switches.
Very harmful tab. If you keep these numbers always in front of your eyes, the project cannot be delivered on time - it will always seem that all operations are performed at least 10 times longer than they could.
Remember: "Premature optimization is the root of all evil."
SettingsVars
Here you can see all the Django settings from the settings.py file of this application. I don’t know if this is of great use - you can always see the config in the file.
Headers
Theoretically, there should be headers of the HTTP request, which led to the display of the investigated page. But actually in this panel I see a list of server environment variables:
Not often needed, but good when such information is at hand.
Request
Here you can see the cookies for this domain, Django session variables, as well as the variables passed in the GET / POST request. You can imagine it without a picture.
Template
The template information panel with which the output occurs. Probably works well when using the native Django template engine. And for outsiders, only viewing contexts works:
SQLDebug
Powerful thing. Shows all database queries, their execution time and full trace.
This allows you to identify a query that is problematic in performance and easily find it even in the most confusing application with template inheritance. It works for any template engine, it seems.
By the way, any query can be executed directly from the panel, and you can also ask for it Explain or even Profile (if the database supports).
Cache
The panel allows you to view write and read acts from the cache, information received, time spent and other cache statistics:
For example, in this picture you can see that there was an attempt to take the update_sites key from the cache, but it turned out to be empty (the cache was expired). Then there was a write to the cache of new data. I want to believe that in the Time column the correct order of numbers and dimension.
Logging
It's like console.log ('Hello'). Prints debugging messages from the logging Python module. To get the debug output, you need to connect the module and say something into it: It is a pity that different message levels are not highlighted.
import logging
logging.info('Пороки этого мира суть метафоры добродетелей мира грядущего.')
How to install
- download something from the official site
- unzip this and run python setup.py install
- add 'debug_toolbar.middleware.DebugToolbarMiddleware' with the last entry in MIDDLEWARE_CLASSES
- add 'debug_toolbar' to INSTALLED_APPS
- configure INTERNAL_IPS correctly - list there ip addresses of developers to whom you can show Debug
- You can still configure some options DEBUG_TOOLBAR
Personally, I only connect debug_toolbar in debug mode: “INTERCEPT_REDIRECTS = False” disables redirect hooking. If you do not disconnect, then first there will be a redirect to the debug page, where it will be described in detail where we were redirected from and to. And the link will be given a click. EXCLUDE_URLS will theoretically someday disable the debugger for the specified directories. Left in order not to forget to try in a year. That would be to cut it down for the necessary subdomains ...
if DEBUG:
MIDDLEWARE_CLASSES += ('debug_toolbar.middleware.DebugToolbarMiddleware',)
INSTALLED_APPS += ('debug_toolbar',)
DEBUG_TOOLBAR_PANELS = (
#'debug_toolbar.panels.version.VersionDebugPanel', # убрать. только место занимает.
'debug_toolbar.panels.timer.TimerDebugPanel',
'debug_toolbar.panels.settings_vars.SettingsVarsDebugPanel',
'debug_toolbar.panels.headers.HeaderDebugPanel',
'debug_toolbar.panels.request_vars.RequestVarsDebugPanel',
'debug_toolbar.panels.template.TemplateDebugPanel',
'debug_toolbar.panels.sql.SQLDebugPanel',
'debug_toolbar.panels.cache.CacheDebugPanel',
'debug_toolbar.panels.logger.LoggingPanel',
)
DEBUG_TOOLBAR_CONFIG = {
'EXCLUDE_URLS': ('/admin',), # не работает, но в разработке есть...
'INTERCEPT_REDIRECTS': False,
}
Problems
The product is a little damp. Its various minor details may not work or work incorrectly. I had to pick a template and js files for about 15 minutes to get the “Hide” button working. The script requires jquery and the cookies plugin (the cookie saves the state of the panel - closed / open). For some reason, the plugin was connected after the toolbar.js script crashed with an error.
For a long time I also miscalculated the formatting of time output in all panels: well, why should I see hundredths of a millisecond? But these are all little things that can be easily dealt with or simply ignored.
There can be difficulties when using some tricky middleware. I had to modify the file class, organizing work with subdomains within the same server.
Addition
There are opinions that this fork of this toolbar is slightly better. I still can’t say exactly about functionality, but the interface ...
For such a debugger interface, someone could sell the soul to the devil! Need to try.
Found a mistake - write to Habrapost.