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.

[itdependsnetworks]

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.

It's fair that you need to store state, and there a limited places you can do that. I think the challenge here is making changes without someone's knowledge, especially in the database, which most would consider sacred. To pull the class xkcd move here... (and with the emphathy of maintaining open source and knowing it stinks to tell people no, as well as it stinks to make everything a configuration option), I do think this warrants a configuration option. In general, I would want the ability to choose

• local filesystem
• cache
• database

While honestly, I would never even consider using database as an option I understand you may. Using the file systems as a store has worked in *Nix since the start.

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.

Agreed the tooling does effect the system I implement on, however, not the database or other systems. If I set one of my 3 instances as a debug system and point to a read only replica of my database, I would not expect their to be change and I feel that is in line with most people's expectations.

[minusf]

I dont want to be just a +1, but I also feel strange about DJDT writing to the application database (even if only in local development)...

Looking at the changelog it's not very clear to me why this is needed or what it is used for:

Added debug_toolbar.store.DatabaseStore for persistent debug data storage.

I see async being mentioned here, but not everyone uses async (myself included) and it puts a maintenance burden on me: I often sync local DB data from staging or even production (where DJDT does not run obviously), and the actual DB schema and migration histories will diverge.

Would it be an idea to make it opt-in? It's a pretty big change after all...

[ertgl]

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.

I'd like to see the database store kept, too. I think we can try to enable on-demand availability by providing the database model via a separate sub app (e.g., debug_toolbar.stores.database). What are your thoughts on this approach, and would you accept a PR?

[tim-schilling]

@ertgl this is going to come up in our contributor discussion in a few weeks. We should have an answer of what direction we want to head after that.

[kakulukia]

I just stumbled onto this thread as my dev server was nagging me about migrations that needed to be applied.

Most of the times in the past that meant that i have actually forgotten something. But from now on i will obviously always get this message as i am mostly using a fresh copy of the production database and with dev-tools disabled over there i see myself foced to downgrade debug-tools as long as there is no setting to completely disable it. :(

[ertgl]

This reminded me that, we should probably keep the migrations' dependency graph clean so that the app/feature can be enabled or disabled depending on the environment, etc.

It seems, this is how it was done before with a managed model, for the caching layer.

• Creating the cache table - Django documentation
• django/core/cache/backends/db.py#L37
• django/core/management/commands/createcachetable.py

[tim-schilling]

i see myself foced to downgrade debug-tools as long as there is no setting to completely disable it.

If you wanted to, you can insert a row into the migrations table on your production database. It'd be the equivalent of running python manage.py migrate debug_toolbar --fake. That would unblock you from upgrading to latest versions of the toolbar, without the runtime warning. Though you should add a note for your future self where the toolbar config is that you'd have to clean that up if you ever wanted to use the table.

[tim-schilling]

@ertgl I'd be against having a command like createcachetable at this point. It's not clear what the future holds for it and trying to roll our own migration system seems error-prone.

[matthiask]

We discussed this issue in our contributor meeting a few weeks back. We're converting this issue into a discussion because we want to keep the discussion going.

The database store was added because saving the debugging data in memory doesn't work in async contexts, because even in development users may have several threads or processes starting, running and stopping. Data saved in one of those processes is gone when the process itself stops, and that would make the toolbar somewhat useless in those circumstances. The toolbar is an important part of the Django ecosystem, and we don't want to hold Django back when people want to use, inspect and debug asynchronous code.

In hindsight, other options would possibly have been slightly better. We think that the upside to moving the store around compared to the problems of the status quo isn't big enough for now.

(I wanted to post this comment on the issue but couldn't unlock it after converting the issue into a discussion.)

[tim-schilling]

I went and fetched the top 10 versions of the toolbar that have been downloaded in the past month. Looks like the majority of folks are still upgrading to 6.0, though there may be more opinions coming as Django 4.2 falls out of support in the future.

version	download_count
6.0.0	1355045
4.3.0	858393
4.2.0	841534
4.4.6	636326
5.2.0	491611
5.0.1	183791
3.2.1	179476
3.8.1	164370
3.2.4	158343
5.1.0	126221

[minusf]

Thank you for the numbers. It's a good ballpark estimation but I am not sure it tells the whole story. I use djdt in all my work and personal projects, but because I use package caching, for any particular version it will show up as "1" download even though I routinely blow away whole venvs all the time.

The really far pull away of 6.0.0 could be partially also because I see very often dev dependencies not pinned in the same way as production dependencies, because, well, they are only for local development, and latest is the greates...

I also wonder how many people noticed the additional migration and/or the warning in their workflows...

[kakulukia]

I will ignore all further updates of django-debug-toolbar as this migration is only available when the module is loaded, which is not the case on the production system. So this is a dead end.

[minusf]

Thank you for these great tips, I didn't know about MIGRATION_MODULES. It would be a great addition to the README because I think not many people know about this feature...

It seems that that solution puts the least amount of burden on project maintenance.

In my workflow I clone production DB's often back to local dev environment and always faking the djdt migration seems like somewhat of an error prone approach.

[tim-schilling]

@minusf The first suggestion would be to insert that row in your production database's django_migrations table so the clones would treat it as faked.

[minusf]

yeah, that's a bit icky to me, sorry 😅

[kakulukia]

2. Disable migrations for the toolbar by adding the setting `MIGRATION_MODULES = {"debug_toolbar": None}` to your project

Have to test this and didnt know about this option existing.

[kakulukia]

Okay, this MIGRATION_MODULES workaround works. Thanks for that. This should be a fat note in the docs.

[tim-schilling]

Version 6.1.0 has been released and will hide the migrations and models.