Database models: a mistake?

[vanschelven]

As a complete non-contributor and visitor to this project, that was just burned by the 6.0 upgrade and as such happened upon this issue, I'd like to say: I think this is a mistake. IMHO a "debug toolbar" should not take it upon itself to write to the DB.

The whole point of a debug tool is to observe what the app is doing -- not to change its behavior in subtle, state-altering ways. Writing to the database just to store debug metadata crosses a line. It can mask real issues (like unexpected writes during GET requests), and it undermines trust in what you're observing.

Even just the idea that the toolbar might require database migrations to function is a red flag. That adds friction to enabling it on demand and makes it harder to drop into a project temporarily. A debugging tool should be lightweight, observational, and ideally disposable -- not something that modifies your schema.

I'm sorry to be so negative, and I won't belabor the point, but at least if others feel the same they'll have a point to come together on.

[tim-schilling]

I appreciate your opinion, but I don't share it. If the other maintainers agree with you, it's possible we remove the database store altogether, but I'm in favor of keeping it at the moment.

That adds friction to enabling it on demand and makes it harder to drop into a project temporarily.

This is an excellent point and something we should look into. It would be great to not need to migrate the db when not using the database store.

[jgb]

I'm just putting my voice behind what @vanschelven said. Long time user of django-debug-toolbar, not planning to use the database store so I would really rather not be forced into migrations.

[matthiask]

Thanks. The problem is that we need a place to store data outside the request/response cycle to support debugging in async environments. We're definitely open to suggestions how to resolve this in different ways.

I don't necessarily think it's totally unexpected that debugging tools have some influence on the way the system works. Excessive logging or instrumentation can slow down a system as well. The toolbar doesn't try being something which can be put into production environments without affecting the environment, so I'm not really what to think about the points raised. The toolbar is more in the tracing corner of debugging tools than in the sampling corner after all.

[vanschelven]

I won't belabor

Well one more thing then 😄

I also wonder what the interactions with database transactions are. Given its broad scope DJDT can hardly make any assumptions about how those are used across projects. That raises at least the following questions:

• How can the DJDT rely on things actually making it to "commit"? e.g. setups in which any error rolls back the whole database transaction (or a large part of it) are quite common. In such setups DJDT would not get the data it relies on (presumably) written to the DB.
• How does the DJDT integrate with application-level expectations on how to behave w.r.t. transactions? For example, in Bugsink, I am explicit about whether a transaction will be writing to the DB or not, and open a transaction accordingly. Writing in a read-only transaction will not be reliable in that setup.