-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add support for enabling/disabling SQLPanel tracking of DDT model queries #2211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 3 commits
c63ee81
efbff9a
9f125bd
115f3a0
2f61273
1fe70b6
cb77283
52d9f14
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -15,6 +15,7 @@ | |||||
from django.test.utils import override_settings | ||||||
|
||||||
import debug_toolbar.panels.sql.tracking as sql_tracking | ||||||
from debug_toolbar.models import HistoryEntry | ||||||
from debug_toolbar.panels.sql import SQLPanel | ||||||
|
||||||
try: | ||||||
|
@@ -33,6 +34,20 @@ def sql_call(*, use_iterator=False): | |||||
return list(qs) | ||||||
|
||||||
|
||||||
def sql_call_ddt(*, use_iterator=False): | ||||||
|
||||||
qs = HistoryEntry.objects.all() | ||||||
if use_iterator: | ||||||
qs = qs.iterator() | ||||||
|
||||||
return list(qs) | ||||||
|
||||||
|
||||||
async def async_sql_call_ddt(*, use_iterator=False): | ||||||
qs = HistoryEntry.objects.all() | ||||||
if use_iterator: | ||||||
qs = qs.iterator() | ||||||
return await sync_to_async(list)(qs) | ||||||
|
||||||
|
||||||
async def async_sql_call(*, use_iterator=False): | ||||||
qs = User.objects.all() | ||||||
if use_iterator: | ||||||
|
@@ -104,6 +119,64 @@ async def test_recording_concurrent_async(self): | |||||
# ensure the stacktrace is populated | ||||||
self.assertTrue(len(query["stacktrace"]) > 0) | ||||||
|
||||||
def test_ddt_models_tracking(self): | ||||||
|
def test_ddt_models_tracking(self): | |
def test_ddt_models_tracked(self): |
nit: Small naming improvement (should be used on the other similar test too)
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may be better off replacing this with a check on the models' table in the sql query rather than these assertions.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def test_ddt_models_untracking(self): | |
def test_ddt_models_not_tracked(self): |
nit: Small naming improvement (should be used on the other similar test too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@theShinigami I don't think I've communicated this idea well. The purpose here is to have a value that enables and disables whether we're using the sql panel. So by default it should track all SQL. However, when we get to the toolbar's own processing, it should be disabled. That way the toolbar isn't monitoring itself. Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tim-schilling I'm not quite getting the idea, could you elaborate a little more? 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given this context var:
Think of the
is_recording
as a global variable that controls whether a panel actually records the activity of the django project. When it'sTrue
, the SQL panel should record SQL queries. When it's False, the SQL panel shouldn't record SQL queries.This comes into play for this issue because we want to disable the SQL panel when the toolbar is processing the request, but not when everything else is.
So we need to identify when to set and when to unset it (somewhere in the middleware most likely, we may run into some weirdness with the async flow), then lastly update the SQL panel to avoid tracking when it's not supposed to.
The places that you'll likely want to update are:
is_recording
hereThis relies on the idea that
record_stats
(what uses the HistoryEntry model) will only ever be called fromgenerate_stats
. I think that will work...Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like I may be missing something here around
enable_instrumentation
anddisable_instrumentation
. This global variable shouldn't be necessary. Sorry, my thoughts aren't fully baked yet